Zbr's days.

About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Fri, 21 Jul 2006

Netchannels.

Our discussion about netchannels ended up with following topics from socket apologists:

  • process context protocol processing allows to have spurious retransmits if receiving side is blocked on some non-tcp task like data writing.
  • atcp works faster because it does not have some features, which if enabled in socket code resulted in worse perfomance.
  • atcp has some bugs (like absence of slow start), which will break connections in some situations, and thus it is faster.

My position is following:
  • socket code and netchannels behave exactly the same, when userspace task is blocked: either socket starts to queue the data and eventually it will drop it due to memory limits, or netchannel will queue the data, but do not process it and send acks. Neither condition can fire in usual life, and if life becomes unusual, troubles will be cought by both sockets and netchannels.
  • no one knows where existing tcp implementation has those features, which should be turned off by default, and no one is motivited enough to start searhing them.
  • atcp has slow start and does not have other specified "bugs", and actually opponent does not know why atcp behaves faster with netchannels (and he agree with me).

Besides above issues, I want to specify my point of view, that netchannels perform faster not only because of different TCP implementation, but because of architectural changes (no BH/irq processing, no bh/irq locks, no complex queue management, no atomic allocations, no false (I mean acks for unread data) acks, thus no possible queue overfull, natural flow control and other things).

According to the idea, that it is impossible to have faster processing (with existing socket code), when protocol management is moved totally into process context, but it was shown with my initial netchannel implementation, that it can be done - and there was small, but 100% reproducible steady performance win (about 2-3 MB/sec and several % of CPU usage) with big-sized chunks. Unfortunately I did not test small-sized ones, which show big perfomance win with netchannels and atcp. Those results were not enough for me, so I implemented different stack, which does not have anything related to the two step processing, and it can be one of the reasons for faster processing. It can have bugs, but the whole idea was proven to be absolutely correct (when using either socket code, or atcp).

After such a discussion, I expect netchannels idea will be buried by linux netdev community, so I think I can say, that this project has completely achieved all designed goals (not to bury the whole idea, but to show that protocol processing in process context can be (sometimes much) faster than two-level usual one) and will be stopped.

Right now I work on the network allocator which can be used both by netchannels and usual networking code to get full zero-copy sending and receiving capabilities.

/devel/networking :: Link / Comments ()