* 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
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(
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 les
* 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 chain
>
> 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
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-triv
> -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
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
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 s
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
> > (e
> -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
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
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
> -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
> n
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 paten
> > 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
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
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
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 neti
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
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 requ
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
> -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
On Sun, 21 Aug 2005, Leonid Grossman wrote:
> Ahh, I was curious to see if someone will bring this argument up - in
> fact, LRO legal issues do not exist, while TOE legal issues are quite
> big at the moment. I guess this is one of the reasons why OpenRDMA and
> other mainstream industry efforts d
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.
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 siz
D]
> 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..
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 a
28 matches
Mail list logo
