diff for duplicates of <200708060951.12408.ossthema@de.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 217ee8e..83c8b1b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,34 +1,33 @@ -Hi J=C3=B6rn +Hi Jörn -On Friday 03 August 2007 15:41, J=C3=B6rn Engel wrote: +On Friday 03 August 2007 15:41, Jörn Engel wrote: > On Fri, 3 August 2007 14:41:19 +0200, Jan-Bernd Themann wrote: -> >=20 +> > > > This patch provides generic Large Receive Offload (LRO) functionality > > for IPv4/TCP traffic. -> >=20 -> > LRO combines received tcp packets to a single larger tcp packet and=20 +> > +> > LRO combines received tcp packets to a single larger tcp packet and > > passes them then to the network stack in order to increase performance > > (throughput). The interface supports two modes: Drivers can either pass -> > SKBs or fragment lists to the LRO engine.=20 ->=20 +> > SKBs or fragment lists to the LRO engine. +> > Maybe this is a stupid question, but why is LRO done at the device > driver level? ->=20 +> > If it is a unversal performance benefit, I would have expected it to be > done generically, i.e. have all packets moved into network layer pass > through LRO instead. The driver seems to be the right place: -=2D There is the "page mode" interface that accepts fragment lists instead= - of - SKBs and does generate SKBs only in the end (see Andrew Gallatins=20 +- There is the "page mode" interface that accepts fragment lists instead of + SKBs and does generate SKBs only in the end (see Andrew Gallatins mails where he described the advantages of this approach) -=2D Some drivers (in particular for 10G NICs which actually could benefit +- Some drivers (in particular for 10G NICs which actually could benefit from LRO) have multiple HW receive queues that do some sort of sorting, thus using one lro_mgr per queue increases the likelyhood of beeing able to do efficient LRO. - =20 + > > +void lro_flush_pkt(struct net_lro_mgr *lro_mgr, > > + struct iphdr *iph, struct tcphdr *tcph); @@ -37,14 +36,12 @@ The driver seems to be the right place: > which would be settable via /proc/sys/net/core/lro_timeout or similar. No, this function is needed for "page mode" as some HW provides -extra handling for small packets where packets are not stored in preallocat= -ed=20 +extra handling for small packets where packets are not stored in preallocated pages but in extra queues. Thus the driver needs a way to flush old sessions -for this connection and handle these packets in a different way (for exampl= -e=20 +for this connection and handle these packets in a different way (for example create a SKB and copy the data there). -Timeouts are not used at all. Experiments showed that flushing at the end=20 +Timeouts are not used at all. Experiments showed that flushing at the end of a NAPI poll round seems to be sufficient (see Andrew's test results) and does not affect the latency too badly. diff --git a/a/content_digest b/N1/content_digest index 92a4e38..8aba2ac 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,50 +4,49 @@ "Subject\0Re: [PATCH 1/1] lro: Generic Large Receive Offload for TCP traffic\0" "Date\0Mon, 6 Aug 2007 09:51:11 +0200\0" "To\0J\303\266rn Engel <joern@logfs.org>\0" - "Cc\0Thomas Klein <tklein@de.ibm.com>" - Jeff Garzik <jeff@garzik.org> + "Cc\0David Miller <davem@davemloft.net>" + Christoph Raisch <raisch@de.ibm.com> Jan-Bernd Themann <themann@de.ibm.com> - netdev <netdev@vger.kernel.org> linux-kernel <linux-kernel@vger.kernel.org> linux-ppc <linuxppc-dev@ozlabs.org> - Christoph Raisch <raisch@de.ibm.com> Marcus Eder <meder@de.ibm.com> + Thomas Klein <tklein@de.ibm.com> + netdev <netdev@vger.kernel.org> Andrew Gallatin <gallatin@myri.com> - Stefan Roscher <stefan.roscher@de.ibm.com> - " David Miller <davem@davemloft.net>\0" + Jeff Garzik <jeff@garzik.org> + " Stefan Roscher <stefan.roscher@de.ibm.com>\0" "\00:1\0" "b\0" - "Hi J=C3=B6rn\n" + "Hi J\303\266rn\n" "\n" - "On Friday 03 August 2007 15:41, J=C3=B6rn Engel wrote:\n" + "On Friday 03 August 2007 15:41, J\303\266rn Engel wrote:\n" "> On Fri, 3 August 2007 14:41:19 +0200, Jan-Bernd Themann wrote:\n" - "> >=20\n" + "> > \n" "> > This patch provides generic Large Receive Offload (LRO) functionality\n" "> > for IPv4/TCP traffic.\n" - "> >=20\n" - "> > LRO combines received tcp packets to a single larger tcp packet and=20\n" + "> > \n" + "> > LRO combines received tcp packets to a single larger tcp packet and \n" "> > passes them then to the network stack in order to increase performance\n" "> > (throughput). The interface supports two modes: Drivers can either pass\n" - "> > SKBs or fragment lists to the LRO engine.=20\n" - ">=20\n" + "> > SKBs or fragment lists to the LRO engine. \n" + "> \n" "> Maybe this is a stupid question, but why is LRO done at the device\n" "> driver level?\n" - ">=20\n" + "> \n" "> If it is a unversal performance benefit, I would have expected it to be\n" "> done generically, i.e. have all packets moved into network layer pass\n" "> through LRO instead.\n" "\n" "The driver seems to be the right place:\n" - "=2D There is the \"page mode\" interface that accepts fragment lists instead=\n" - " of\n" - " SKBs and does generate SKBs only in the end (see Andrew Gallatins=20\n" + "- There is the \"page mode\" interface that accepts fragment lists instead of\n" + " SKBs and does generate SKBs only in the end (see Andrew Gallatins \n" " mails where he described the advantages of this approach)\n" "\n" - "=2D Some drivers (in particular for 10G NICs which actually could benefit\n" + "- Some drivers (in particular for 10G NICs which actually could benefit\n" " from LRO) have multiple HW receive queues that do some sort of sorting,\n" " thus using one lro_mgr per queue increases the likelyhood of beeing able\n" " to do efficient LRO.\n" - " =20\n" + " \n" "\n" "> > +void lro_flush_pkt(struct net_lro_mgr *lro_mgr,\n" "> > +\t\t struct iphdr *iph, struct tcphdr *tcph);\n" @@ -56,18 +55,16 @@ "> which would be settable via /proc/sys/net/core/lro_timeout or similar.\n" "\n" "No, this function is needed for \"page mode\" as some HW provides\n" - "extra handling for small packets where packets are not stored in preallocat=\n" - "ed=20\n" + "extra handling for small packets where packets are not stored in preallocated \n" "pages but in extra queues. Thus the driver needs a way to flush old sessions\n" - "for this connection and handle these packets in a different way (for exampl=\n" - "e=20\n" + "for this connection and handle these packets in a different way (for example \n" "create a SKB and copy the data there).\n" "\n" - "Timeouts are not used at all. Experiments showed that flushing at the end=20\n" + "Timeouts are not used at all. Experiments showed that flushing at the end \n" "of a NAPI poll round seems to be sufficient (see Andrew's test results)\n" "and does not affect the latency too badly.\n" "\n" "Regards,\n" Jan-Bernd -8c7cb4b1c47b6a4e89cf9fbc722f4ba63a5277248854d1589f42008987ad5eaf +d8bd8ec25425ac3cdcefaeff9c9b0490a4503f7249eed41bb528c01479f19fe4
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.