From: "Jörn Engel" <joern@logfs.org>
To: Jan-Bernd Themann <ossthema@de.ibm.com>
Cc: Thomas Klein <tklein@de.ibm.com>, Jeff Garzik <jeff@garzik.org>,
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>,
Andrew Gallatin <gallatin@myri.com>,
Stefan Roscher <stefan.roscher@de.ibm.com>,
David Miller <davem@davemloft.net>
Subject: Re: [PATCH 1/1] lro: Generic Large Receive Offload for TCP traffic
Date: Fri, 3 Aug 2007 15:41:50 +0200 [thread overview]
Message-ID: <20070803134150.GH19344@lazybastard.org> (raw)
In-Reply-To: <200708031441.20632.ossthema@de.ibm.com>
On Fri, 3 August 2007 14:41:19 +0200, Jan-Bernd Themann wrote:
>
> This patch provides generic Large Receive Offload (LRO) functionality
> for IPv4/TCP traffic.
>
> 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.
Maybe this is a stupid question, but why is LRO done at the device
driver level?
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.
> +void lro_flush_pkt(struct net_lro_mgr *lro_mgr,
> + struct iphdr *iph, struct tcphdr *tcph);
In particular this bit looks like it should be driven by a timeout,
which would be settable via /proc/sys/net/core/lro_timeout or similar.
Jörn
--
Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
-- M.A. Jackson
WARNING: multiple messages have this Message-ID (diff)
From: "Jörn Engel" <joern@logfs.org>
To: Jan-Bernd Themann <ossthema@de.ibm.com>
Cc: David Miller <davem@davemloft.net>,
Christoph Raisch <raisch@de.ibm.com>,
Jan-Bernd Themann <themann@de.ibm.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-ppc <linuxppc-dev@ozlabs.org>,
Marcus Eder <meder@de.ibm.com>, Thomas Klein <tklein@de.ibm.com>,
netdev <netdev@vger.kernel.org>,
Andrew Gallatin <gallatin@myri.com>,
Jeff Garzik <jeff@garzik.org>,
Stefan Roscher <stefan.roscher@de.ibm.com>
Subject: Re: [PATCH 1/1] lro: Generic Large Receive Offload for TCP traffic
Date: Fri, 3 Aug 2007 15:41:50 +0200 [thread overview]
Message-ID: <20070803134150.GH19344@lazybastard.org> (raw)
In-Reply-To: <200708031441.20632.ossthema@de.ibm.com>
On Fri, 3 August 2007 14:41:19 +0200, Jan-Bernd Themann wrote:
>
> This patch provides generic Large Receive Offload (LRO) functionality
> for IPv4/TCP traffic.
>
> 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.
Maybe this is a stupid question, but why is LRO done at the device
driver level?
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.
> +void lro_flush_pkt(struct net_lro_mgr *lro_mgr,
> + struct iphdr *iph, struct tcphdr *tcph);
In particular this bit looks like it should be driven by a timeout,
which would be settable via /proc/sys/net/core/lro_timeout or similar.
Jörn
--
Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
-- M.A. Jackson
next prev parent reply other threads:[~2007-08-03 14:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-03 12:41 [PATCH 1/1] lro: Generic Large Receive Offload for TCP traffic Jan-Bernd Themann
2007-08-03 12:41 ` Jan-Bernd Themann
2007-08-03 13:41 ` Jörn Engel [this message]
2007-08-03 13:41 ` Jörn Engel
2007-08-06 7:51 ` Jan-Bernd Themann
2007-08-06 7:51 ` Jan-Bernd Themann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070803134150.GH19344@lazybastard.org \
--to=joern@logfs.org \
--cc=davem@davemloft.net \
--cc=gallatin@myri.com \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=meder@de.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=ossthema@de.ibm.com \
--cc=raisch@de.ibm.com \
--cc=stefan.roscher@de.ibm.com \
--cc=themann@de.ibm.com \
--cc=tklein@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.