Comments on: He who divides and shares is left with the best share http://digitalvampire.org/blog/index.php/2007/11/06/he-who-divides-and-shares-is-left-with-the-best-share/ Linux hacker, recovering mathematician, former athlete Fri, 11 Mar 2011 20:17:40 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: !foo http://digitalvampire.org/blog/index.php/2007/11/06/he-who-divides-and-shares-is-left-with-the-best-share/comment-page-1/#comment-413 !foo Sun, 09 Dec 2007 20:40:05 +0000 http://digitalvampire.org/blog/index.php/2007/11/06/he-who-divides-and-shares-is-left-with-the-best-share/#comment-413 I think the institutional and traditional outlook evinced by the native ip stack devs (in the absence of non-conflicting suggestions from the (RDMA/iWARP) devs) is not out of line. The comment linked to, while negative, had the merit of not suggesting a further division of the standard methgod of BSD socket port allocation. Granted the benefit to traditional network filesystems,etc.. seems potentially considerable. The lack of hardware/kernel communication seems to be an issue that should be dealt with by an iWARP nic driver with hooks deep enough to ensure no port allocation conflict occurs. What does that take? I think the institutional and traditional outlook evinced by the native ip stack devs (in the absence of non-conflicting suggestions from the (RDMA/iWARP) devs) is not out of line. The comment linked to, while negative, had the merit of not suggesting a further division of the standard methgod of BSD socket port allocation.
Granted the benefit to traditional network filesystems,etc.. seems potentially considerable.
The lack of hardware/kernel communication seems to be an issue that should be dealt with by an iWARP nic driver with hooks deep enough to ensure no port allocation conflict occurs. What does that take?

]]> By: roland http://digitalvampire.org/blog/index.php/2007/11/06/he-who-divides-and-shares-is-left-with-the-best-share/comment-page-1/#comment-365 roland Tue, 06 Nov 2007 21:31:00 +0000 http://digitalvampire.org/blog/index.php/2007/11/06/he-who-divides-and-shares-is-left-with-the-best-share/#comment-365 I'm not really sure who the "Oh, think for a minute" reply is ranting at. Who has decided on one solution? Who is refusing to work with people rather than whining? It sure sounds targeted at the people who stick to the "TOE is evil" mantra and refuse to look for common ground, but the last paragraph seems to be aimed at the people trying to work with the whole Linux networking community and make iWARP work a little better. More specifically, how do callbacks into the kernel make it possible to avoid having both a normal TCP socket and an iWARP socket bound to the same 4-tuple? There's no call-back needed, since the kernel is fully aware of all the state at the time an application does a bind(), and I don't see how a call-back helps anyway. I’m not really sure who the “Oh, think for a minute” reply is ranting at. Who has decided on one solution? Who is refusing to work with people rather than whining? It sure sounds targeted at the people who stick to the “TOE is evil” mantra and refuse to look for common ground, but the last paragraph seems to be aimed at the people trying to work with the whole Linux networking community and make iWARP work a little better.

More specifically, how do callbacks into the kernel make it possible to avoid having both a normal TCP socket and an iWARP socket bound to the same 4-tuple? There’s no call-back needed, since the kernel is fully aware of all the state at the time an application does a bind(), and I don’t see how a call-back helps anyway.

]]> By: Oh, think for a minute. http://digitalvampire.org/blog/index.php/2007/11/06/he-who-divides-and-shares-is-left-with-the-best-share/comment-page-1/#comment-364 Oh, think for a minute. Tue, 06 Nov 2007 21:17:58 +0000 http://digitalvampire.org/blog/index.php/2007/11/06/he-who-divides-and-shares-is-left-with-the-best-share/#comment-364 I suppose no other protocols involve a control-plane / data-plane split. And there's never been direct-access hardware before. Nope. No graphics adapters. No "old" high-speed networks. Nope nope. You've decided on *one* solution. It's not widely acceptable. Come up with another. Geez. Maybe the hardware that's out there isn't as perfect as you would like to believe. One absolutely radical idea would be call-backs to the kernel from within the NIC's state machine. Yeah, this exposes some other problems with scheduling. You aren't the only one seeing those, so maybe you could work *with* other people rather than whining. But no, this is high-performance. All rules must go out the window for a high-performance adapter. After all, it'll be high-performance for at least another 6 months before something else comes along. I suppose no other protocols involve a control-plane / data-plane split. And there’s never been direct-access hardware before. Nope. No graphics adapters. No “old” high-speed networks. Nope nope.

You’ve decided on *one* solution. It’s not widely acceptable. Come up with another. Geez. Maybe the hardware that’s out there isn’t as perfect as you would like to believe.

One absolutely radical idea would be call-backs to the kernel from within the NIC’s state machine. Yeah, this exposes some other problems with scheduling. You aren’t the only one seeing those, so maybe you could work *with* other people rather than whining.

But no, this is high-performance. All rules must go out the window for a high-performance adapter. After all, it’ll be high-performance for at least another 6 months before something else comes along.

]]>