Re: LRO Patent vs. patent free TOE
* David S. Miller <[EMAIL PROTECTED]> 2005-08-23 10:35 > Currently NETIF_F_SG drivers do not wake up the TX queue > until MAX_SKB_FRAGS descriptors are ready, now they'll > have to defer until (N * MAX_SKB_FRAGS) are available. > > And even for a low value of "N" like 3 this is a whopping _54_ TX > descriptors on 4K PAGE_SIZE platforms. Heck, many drivers do not come > up with that many TX descriptors available, in total! > > And it's unthinkable to put this TX queue emptyness knowledge > into the generic queueing layer. Poor man's TSO is definitely > not worth this. Maybe not in the generic queueing layer but we can provide a specific qdisc which would be aware of this and could provide chained skbs with a configureable N. The qdisc could either rely on having a at least partly filled queue or use a timer to give every skb a few jiffies delay to wait for other skbs useable for chaining. The major issues on this would be in qdisc_restart() so we'd probably have to extend the api and add a dequeue_chain() and only use it if both the device and qdisc support it. Just a thought but this would probably be the easiest implementation which could still result in some gain. It's not poor man's TSO anymore though ;). - 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
Re: LRO Patent vs. patent free TOE
David S. Miller wrote: From: Thomas Graf <[EMAIL PROTECTED]> Date: Tue, 23 Aug 2005 19:00:54 +0200 Setting txqlen of the device to 2*MAX_CHAINLEN should be sufficient in most cases. We'd probably have to modify the kick/watchdog a bit to actually get the packets out faster because the enqueue()s would happen less frequently, would have to look into this. Oh yes, that's the other problem with this idea. Currently NETIF_F_SG drivers do not wake up the TX queue until MAX_SKB_FRAGS descriptors are ready, now they'll have to defer until (N * MAX_SKB_FRAGS) are available. And even for a low value of "N" like 3 this is a whopping _54_ TX descriptors on 4K PAGE_SIZE platforms. Heck, many drivers do not come up with that many TX descriptors available, in total! And it's unthinkable to put this TX queue emptyness knowledge into the generic queueing layer. Poor man's TSO is definitely not worth this. Would it help to have a call-back, perhaps triggered by the netif_wake_queue method in netdevice.h? This helped me get another 30% of traffic out of my application on realtek NICs (with a pitiful 4 packet transmit queue). Threads trying to write to the adapter could register themselves as interested in the callbacks when the write fails due to tx buffer full, for instance. Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - 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
Re: LRO Patent vs. patent free TOE
From: Thomas Graf <[EMAIL PROTECTED]> Date: Tue, 23 Aug 2005 19:00:54 +0200 > Setting txqlen of the device to 2*MAX_CHAINLEN should be sufficient > in most cases. We'd probably have to modify the kick/watchdog a bit > to actually get the packets out faster because the enqueue()s would > happen less frequently, would have to look into this. Oh yes, that's the other problem with this idea. Currently NETIF_F_SG drivers do not wake up the TX queue until MAX_SKB_FRAGS descriptors are ready, now they'll have to defer until (N * MAX_SKB_FRAGS) are available. And even for a low value of "N" like 3 this is a whopping _54_ TX descriptors on 4K PAGE_SIZE platforms. Heck, many drivers do not come up with that many TX descriptors available, in total! And it's unthinkable to put this TX queue emptyness knowledge into the generic queueing layer. Poor man's TSO is definitely not worth this. - 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
Re: LRO Patent vs. patent free TOE
* David S. Miller <[EMAIL PROTECTED]> 2005-08-23 09:15 > There are actually some non-trivial issues wrt. this. We would > need to loop inside of the packet scheduler, and netfilter, to do > correct traffic classification and firewalling. > > But I guess we could deal with that by supporting chaining in > those subsystems. It looks ugly though, what to do if the > first packet is marked as "delay" by the packet scheduler, > but the rest are allowed to pass through to the device right > now? Do we unlink the one which will be delayed? It's non-trivial to make a statement on this, it heavly depends on the complexity of the qdiscs being used. I guess the majority which would actually benefit from this chaining is not interested in classification by packet inspection but rather if at all only based on dscp so at least the whole chain could be enqueued into the same queue/band at first. I hardly think chaining will be of use at all if a certain level of congestion is reached so it should be possible to keep the queues mostly empty. Setting txqlen of the device to 2*MAX_CHAINLEN should be sufficient in most cases. We'd probably have to modify the kick/watchdog a bit to actually get the packets out faster because the enqueue()s would happen less frequently, would have to look into this. - 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
Re: LRO Patent vs. patent free TOE
> > There are actually some non-trivial issues wrt. this. We would > need to loop inside of the packet scheduler, and netfilter, to do > correct traffic classification and firewalling. It could be introduced slowly, with some compat code that just falls back to packet at a time mode (like it has been done with netfilter for non linear skbs for a long time). At the beginning just the fast path counts. I like this also because it has the chance to lower lock and atomic instruction overhead. e.g. when you have a train of packets from all the same device you could do a "bulk" atomic_add and sub on the device counters and only take the various locks once. Andrew used to introduce such tricks into the VM and it helped quite a lot for some loads. > > But I guess we could deal with that by supporting chaining in > those subsystems. It looks ugly though, what to do if the > first packet is marked as "delay" by the packet scheduler, > but the rest are allowed to pass through to the device right > now? Do we unlink the one which will be delayed? Why not? If quick unlinking is a problem something would be wrong with the design. -Andi - 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
Re: LRO Patent vs. patent free TOE
From: "Leonid Grossman" <[EMAIL PROTECTED]> Date: Tue, 23 Aug 2005 12:08:21 -0400 > There are also stack implementations that support transmit for more than > one packet at the time, and the improvements are noticeable. Yes, this is Solaris's "poor man's TSO" :-) There are actually some non-trivial issues wrt. this. We would need to loop inside of the packet scheduler, and netfilter, to do correct traffic classification and firewalling. But I guess we could deal with that by supporting chaining in those subsystems. It looks ugly though, what to do if the first packet is marked as "delay" by the packet scheduler, but the rest are allowed to pass through to the device right now? Do we unlink the one which will be delayed? Similar situations arise in the firewalling too, and this isn't unrealistic as this is exactly what packet schedulers like netem will do. - 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
RE: LRO Patent vs. patent free TOE
> -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED] > On the other hand it might make sense to do this even on > hardware that doesn't support TSO - many card designs can > submit a list of packets more efficiently than each packet at > a time. If anything the cost of taking the driver lock will be lower. > Ditto. This is actually somewhat orthogonal to TSO, but some cards (including ours) are indeed optimized for handling "packet trains" (bus transfer efficiency, etc). There are also stack implementations that support transmit for more than one packet at the time, and the improvements are noticeable. - 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
Re: LRO Patent vs. patent free TOE
On Tuesday 23 August 2005 18:01, David S. Miller wrote: > From: Andi Kleen <[EMAIL PROTECTED]> > Date: Tue, 23 Aug 2005 17:53:58 +0200 > > > However the drawback is that you would likely need to > > submit the packets as two pieces (payload and header) > > which would need more accesses to TX rings and could > > slow down the hardware. > > > > I'm not sure the whole software shim scheme is a good idea. > > It has too many drawbacks. > > We'll see, it's at least worth the try :) The biggest issue I forgot is that most drivers don't even support NETIF_F_SG. So on those to insert the header you would need to copy all data. -Andi - 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
Re: LRO Patent vs. patent free TOE
From: Andi Kleen <[EMAIL PROTECTED]> Date: Tue, 23 Aug 2005 17:53:58 +0200 > However the drawback is that you would likely need to > submit the packets as two pieces (payload and header) > which would need more accesses to TX rings and could > slow down the hardware. > > I'm not sure the whole software shim scheme is a good idea. > It has too many drawbacks. We'll see, it's at least worth the try :) - 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
Re: LRO Patent vs. patent free TOE
On Tuesday 23 August 2005 17:21, David S. Miller wrote: > From: "Leonid Grossman" <[EMAIL PROTECTED]> > Date: Tue, 23 Aug 2005 02:25:07 -0400 > > > On a more serious note, I'm all in for stateless offloads but I think > > that dropping stack support for adapters that don't implement TSO, etc > > (either in hardware or in the driver) is a pretty long shot - someone > > will have to update all the legacy drivers out there. > > We're not dropping support, the idea is to have a software > shim that does the offload in software if the hardware isn't > doing it. > > This will actually decrease TCP stack processing at the cost > of some minimal work in the software shim. And, as a result, > we can remove all of the "if (device supports TSO)" checks > all over the place in the TCP stack, we can just assume the > facility is available all the time. Hmm - one problem is that you would lose copy checksum on NICs that don't do hardware checksumming because if you handle multiple packet as a big piece there is no easy way to reconstruct the individual MSS sized checksums (or at least not without a lot of the overhead individual packet processing has) Doing the additional checksums could be quite expensive and would cost Linux one advantage over BSD stacks :) On the other hand it might make sense to do this even on hardware that doesn't support TSO - many card designs can submit a list of packets more efficiently than each packet at a time. If anything the cost of taking the driver lock will be lower. The trick would be to design the software shim in a way that such optimizations are easily possible, e.g. by separating the code to add headers/compute checksums However the drawback is that you would likely need to submit the packets as two pieces (payload and header) which would need more accesses to TX rings and could slow down the hardware. I'm not sure the whole software shim scheme is a good idea. It has too many drawbacks. -Andi - 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
RE: LRO Patent vs. patent free TOE
> -Original Message- > From: Arnaldo Carvalho de Melo [mailto:[EMAIL PROTECTED] > > No, idea would be to have a library that implements TSO in > software, perhaps with function pointers in struct > net_device, if the drivers don't fill the pointers > register_netdev would fill them with the TSO in software > function pointers, i.e. the (legacy) network card would > "offload" TSO to the OS, thus the TSO^2 (TSOO) joke 8) I.e. > no changes whatsoever to the existing drivers for cards that > don't implement TSO (or LRO or LSO with similar tricks for a > soft implementation). > > Look, from me this is just conceptual handwaving so far 8) > > - Arnaldo > OK, I got it now. The "software shim" idea makes sense. - 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
Re: LRO Patent vs. patent free TOE
From: "Leonid Grossman" <[EMAIL PROTECTED]> Date: Tue, 23 Aug 2005 02:25:07 -0400 > On a more serious note, I'm all in for stateless offloads but I think > that dropping stack support for adapters that don't implement TSO, etc > (either in hardware or in the driver) is a pretty long shot - someone > will have to update all the legacy drivers out there. We're not dropping support, the idea is to have a software shim that does the offload in software if the hardware isn't doing it. This will actually decrease TCP stack processing at the cost of some minimal work in the software shim. And, as a result, we can remove all of the "if (device supports TSO)" checks all over the place in the TCP stack, we can just assume the facility is available all the time. - 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
Re: LRO Patent vs. patent free TOE
On 8/23/05, Leonid Grossman <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > > From: Arnaldo Carvalho de Melo [mailto:[EMAIL PROTECTED] > > Leonid, > > > > If not for performance the idea of having LRO, LSO, TSO, etc > > implemented in software can possibly simplify the stack as it > > would assume that all drivers implement those features, if > > not in hardware in software. > > > > - Arnaldo > > > > If a modern NIC doesn't support TSO in hardware, it deserves to be > outlawed :-) > > On a more serious note, I'm all in for stateless offloads but I think > that dropping stack support for adapters that don't implement TSO, etc > (either in hardware or in the driver) is a pretty long shot - someone > will have to update all the legacy drivers out there. No, idea would be to have a library that implements TSO in software, perhaps with function pointers in struct net_device, if the drivers don't fill the pointers register_netdev would fill them with the TSO in software function pointers, i.e. the (legacy) network card would "offload" TSO to the OS, thus the TSO^2 (TSOO) joke 8) I.e. no changes whatsoever to the existing drivers for cards that don't implement TSO (or LRO or LSO with similar tricks for a soft implementation). Look, from me this is just conceptual handwaving so far 8) - Arnaldo - 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
RE: LRO Patent vs. patent free TOE
> -Original Message- > From: Arnaldo Carvalho de Melo [mailto:[EMAIL PROTECTED] > Leonid, > > If not for performance the idea of having LRO, LSO, TSO, etc > implemented in software can possibly simplify the stack as it > would assume that all drivers implement those features, if > not in hardware in software. > > - Arnaldo > If a modern NIC doesn't support TSO in hardware, it deserves to be outlawed :-) On a more serious note, I'm all in for stateless offloads but I think that dropping stack support for adapters that don't implement TSO, etc (either in hardware or in the driver) is a pretty long shot - someone will have to update all the legacy drivers out there. But if this is what you want to do in the future, you should go ahead and take my waiver offer, just to have a peace of mind. - 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
Re: LRO Patent vs. patent free TOE
On 8/23/05, Leonid Grossman <[EMAIL PROTECTED]> wrote: > > > > 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, > > > > 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. > > - software-only LRO doesn't seem to be a win since it will essentially > shift processing from the stack to the driver. Leonid, If not for performance the idea of having LRO, LSO, TSO, etc implemented in software can possibly simplify the stack as it would assume that all drivers implement those features, if not in hardware in software. - Arnaldo - 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
RE: LRO Patent vs. patent free TOE
> > 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
Re: LRO Patent vs. patent free TOE
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> Date: Mon, 22 Aug 2005 23:57:48 -0300 > i.e. to have a TSO software implementation used only when the card > didn't supported TSO, same stuff, like you mentioned above, for LRO > and LSO, probably/possibly simplifying the stack by making it assume > all net cards had these features and not doing open coded feature > "capacity queries" sprinkled all over the place. Yes, and the other benefit is one Andi Kleen has been after which is to batch packet send calls into the driver. - 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
Re: LRO Patent vs. patent free TOE
On 8/22/05, David S. Miller <[EMAIL PROTECTED]> wrote: > From: Andi Kleen <[EMAIL PROTECTED]> > Date: Tue, 23 Aug 2005 04:31:02 +0200 > > > BTW a software only LRO would be quite imaginable too. > > Absolutely, and it would be excellent for prototyping. > > Most receive offload technologies can be experimented with using a > software simulator that sits watching netif_receive_skb() calls. > > The same for send side schemes as well, the loopback driver can do > LSO for example :-) Yes, great stuff, while in Canada I _very_ briefly thought and mentioned, IIRC to Jamal, Thomas or Patrick about "TSO squared", TSOO, TSO Offload, i.e. to have a TSO software implementation used only when the card didn't supported TSO, same stuff, like you mentioned above, for LRO and LSO, probably/possibly simplifying the stack by making it assume all net cards had these features and not doing open coded feature "capacity queries" sprinkled all over the place. - Arnaldo - 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
Re: LRO Patent vs. patent free TOE
From: Andi Kleen <[EMAIL PROTECTED]> Date: Tue, 23 Aug 2005 04:31:02 +0200 > BTW a software only LRO would be quite imaginable too. Absolutely, and it would be excellent for prototyping. Most receive offload technologies can be experimented with using a software simulator that sits watching netif_receive_skb() calls. The same for send side schemes as well, the loopback driver can do LSO for example :-) - 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
Re: LRO Patent vs. patent free TOE
On Mon, 22 Aug 2005 19:19:06 -0700 (PDT) "David S. Miller" <[EMAIL PROTECTED]> wrote: > 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. This would have the nice side effect that the redundant ACK floods from mitigation you complained about earlier would be gone. -Andi - 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
Re: LRO Patent vs. patent free TOE
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, so I wonder why people keep saying there are software patent issues wrt. LRO. The stack already can receive chained larger-than-MSS frames transparently if the NIC should choose to do so. There is no "software" to add in order to support LRO. I feel like I've stated this at least 3 times already. :-) - 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
Re: LRO Patent vs. patent free TOE
On Mon, 22 Aug 2005 08:57:45 -0700 (PDT) "David S. Miller" <[EMAIL PROTECTED]> wrote: > From: "Leonid Grossman" <[EMAIL PROTECTED]> > Date: Mon, 22 Aug 2005 11:50:54 -0400 > > > Christoph - sorry, but I don't see a reason to continue this debate. > > Good luck fighting TOE patents - you are going to need it. > > I would like to thank Lenoid for making me aware of the > legal concerns TOE brings about. 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. -Andi - 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
RE: LRO Patent vs. patent free TOE
> -Original Message- > From: Christoph Lameter [mailto:[EMAIL PROTECTED] Hi Christoph, You got your subject backwards, but this is OK... > How much will the permission cost for a hardware vendor to be > allowed to implement LRO? The question did not even occur to me until you asked - we are technology company not an IP company. As one man opinion, if and when the application goes through we should "opensource" it in order to facilitate a more generic NIC implementation. The LRO driver code will be obviously released under GPL much earlier. In the meantime, if any NIC vendor wants to copy our implementation rather than create their own, please send us a formal request and we will create a precedent; this may be the only way to convince skeptics :-) > > That is not true. The proposed implementation is not covered > by the lawsuit. Chelsio got a legal review before posting the > patches to insure that this is not the case. With several tens of already granted and very broad TOE-related patents, this statement sounds rather naïve, and I just wish anyone good luck defending it in the future... Are you saying that if both Linux community and IHVs were to implement the proposed TOE interface, they are "guaranteed" not to violate any third-party IP?? Only broad industry consortium with enough joint IP could possibly guarantee that. I would love to see the review you are referring to, but do not hold my breath :-). - 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
RE: LRO Patent vs. patent free TOE
On Mon, 22 Aug 2005, Leonid Grossman wrote: > With several tens of already granted and very broad TOE-related patents, > this statement sounds rather naïve, and I just wish anyone good luck > defending it in the future... Ummm. TOE has been around for 20 years now and there is lots of prior art. The TOE patents that exist are actually very specific. This statement is just FUD. The proposed TOE interface allows an implementation of LRO in the context of a TOE offload module. We would not have to put the patented LRO algorithm into the TCP layer if our proposed interface would be adopted. The LRO TOE offload module would be device driver like, could be written by Neterion and be maintained by you. AFAIK that is the best way to isolate patented technology like yours.
Re: LRO Patent vs. patent free TOE
From: Christoph Lameter <[EMAIL PROTECTED]> Date: Mon, 22 Aug 2005 08:21:34 -0700 (PDT) > We would not have to put the patented > LRO algorithm into the TCP layer There is no "algorithm" to put into the Linux kernel in order to support LRO. The kernel just passively receives larger than MSS sized packets, and the kernel handles that perfectly fine right now without modification. - 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
RE: LRO Patent vs. patent free TOE
> -Original Message- > From: Christoph Lameter [mailto:[EMAIL PROTECTED] > Sent: Monday, August 22, 2005 8:22 AM > To: Leonid Grossman > Cc: David S. Miller; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > netdev@vger.kernel.org; [EMAIL PROTECTED] > Subject: RE: LRO Patent vs. patent free TOE > > On Mon, 22 Aug 2005, Leonid Grossman wrote: > > With several tens of already granted and very broad TOE-related > > patents, this statement sounds rather naïve, and I just > wish anyone good luck defending it in the future... > > Ummm. TOE has been around for 20 years now and there is lots > of prior art. > The TOE patents that exist are actually very specific. This > statement is just FUD. Christoph - sorry, but I don't see a reason to continue this debate. Good luck fighting TOE patents - you are going to need it. - 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
Re: LRO Patent vs. patent free TOE
From: "Leonid Grossman" <[EMAIL PROTECTED]> Date: Mon, 22 Aug 2005 11:50:54 -0400 > Christoph - sorry, but I don't see a reason to continue this debate. > Good luck fighting TOE patents - you are going to need it. I would like to thank Lenoid for making me aware of the legal concerns TOE brings about. - 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
