> > From: Andi Kleen <[EMAIL PROTECTED]> > > Date: Tue, 23 Aug 2005 01:44:34 +0200 > > > > > To be fair the situation as seen from the Linux kernel software > > > perspective is very similar for TOE and for LSO - both > are patented > > > by someone and it might be better to not touch any of > them because of that. > > > > LRO requires no software support, > > Certainly at least the Linux driver which is part of the > source needs to know about it. That will be right in the > source tree. And I suspect longer term some more stack > changes for LRO will be needed too to make it behave better > on the wire. > > BTW a software only LRO would be quite imaginable too. All > you would need is a check if a burst of packets belongs to > the same destination and if yes the stack could process it as > a single unit. Not sure if it would be really a win because > it would need some cache misses to look at the headers, but > perhaps it could be done with a early prefetch and some > interleaving of operations.
Hi Andi, Not sure any of your concerns is valid, specifically: - Linux Driver code for LRO will be GPLed, and therefore available for copy; - David is right about LRO requiring no stack support in order to operate, and any future enhancements are obviously not covered by Neterion application; - software-only LRO doesn't seem to be a win since it will essentially shift processing from the stack to the driver. But if you still have concerns, let me know and I will discuss this within the Company; I personally don't see a reason why we can't provide a release/waiver for any LRO-related Linux code that will be written in the future. Not sure how the actual language would look like (since the patent is not even granted yet), but we can ask one of OSDL lawyers to come up with an appropriate text. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
