[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <200707301724.33865.ossthema@de.ibm.com>
Date: Mon, 30 Jul 2007 17:24:33 +0200
From: Jan-Bernd Themann <ossthema@...ibm.com>
To: netdev <netdev@...r.kernel.org>
Cc: Christoph Raisch <raisch@...ibm.com>,
"Jan-Bernd Themann" <themann@...ibm.com>,
"linux-kernel" <linux-kernel@...r.kernel.org>,
"linux-ppc" <linuxppc-dev@...abs.org>,
Marcus Eder <meder@...ibm.com>,
Thomas Klein <tklein@...ibm.com>,
Stefan Roscher <stefan.roscher@...ibm.com>,
David Miller <davem@...emloft.net>,
Andrew Gallatin <gallatin@...i.com>,
Jeff Garzik <jeff@...zik.org>
Subject: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
Hi,
this patch set contains the latest generic LRO code, a Kconfig / Makefile
and an eHEA patch demonstrating how the "aggregate SKB" interface has to
to be used.
Drew, could you provide a patch for the myri10ge driver to show how the
"receive in page" interface works?
Please check the Kconfig / Makefile patch. Is that the right place for
the LRO entries?
There is still one open question for the "receive in page" mode:
How many data (length) has to be copied to skb->data for packets that
do not work for LRO (other protocols?). Currently I choose 64 as default.
Is that ok?
Thanks,
Jan-Bernd
[PATCH 1/4][RFC] lro: Generic Large Receive Offload for TCP traffic
[PATCH 2/4][RFC] lro: Kconfig and Makefile
[PATCH 3/4][RFC] ehea: LRO support
[PATCH 4/4][RFC] ehea: Kconfig
Changes to http://www.spinics.net/lists/netdev/msg36912.html
1) A new field called "features" has been added to the net_lro_mgr struct.
It is set by the driver to indicate:
- LRO_F_NAPI: Use NAPI / netif_rx to pass packets to stack
- LRO_F_EXTRACT_VLAN_ID: Set by driver if HW extracts VLAN IDs for VLAN
packets but does not modify ETH protocol (ETH_P_8021Q)
2) Padded frames are not aggregated for now. Bug fixed
3) Correct header length now used. No minimal header length for aggregated
packets used anymore.
4) Statistic counters were introduced. They are stored in a new struct in
the net_lro_mgr. This has the advantage that no locking is required in
cases where the driver uses multiple lro_mgrs for different receive queues.
Thus we get the following statistics per lro_mgr / eth device:
- Number of aggregated packets
- Number of flushed packets
- Number of times we run out of lro_desc.
The ratio of "aggregated packets" and "flushed packets" give you an
idea how well LRO is working.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists