public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@davemloft.net>
To: Radheka Godse <radheka.godse@intel.com>
Cc: bonding-devel@lists.sourceforge.net, fubar@us.ibm.com,
	ctindel@users.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [Bonding-devel][PATCH]Zero Copy Transmit Support (Update)
Date: Thu, 11 Nov 2004 16:00:21 -0800	[thread overview]
Message-ID: <20041111160021.5c586095.davem@davemloft.net> (raw)
In-Reply-To: <Pine.LNX.4.61.0411121515530.15487@localhost.localdomain>

On Fri, 12 Nov 2004 15:51:49 -0800 (PST)
Radheka Godse <radheka.godse@intel.com> wrote:

> -
> + 
> +	/* We let the bond device publish all hardware
> +	 * acceleration features possible. This is OK,
> +	 * since if an skb is passed from the bond to
> +	 * a slave that doesn't support one of those
> +	 * features, everything is fixed in the
> +	 * dev_queue_xmit() function (e.g. calculate
> +	 * check sum, linearize the skb, etc.).
> +	 */

This is very inefficient if the bond slaves don't
support these features.

I believe you when you say you saw improvement in the
case where the slaves do support TSO, but if you test
a non-TSO slave case I bet you'll see a marked
decrease in system utilization at least.

The upper layers need to know the precise capabilities
of the device in order to optimize the copy from userspace,
the checksumming, and the data gathering into the SKB.

Therefore, if you "fake it out" like this without checking
what the slaves actually support, then a lot of wasted cpu
time will be spent in each dev_queue_xmit() path.  There will
in many cases be multiple passes over the data instead of one,
and it is possible to introduce an extra data copy as well.

I would recommend instead the following algorithm.  Publish
only the capabilities which all slaves support.

  reply	other threads:[~2004-11-12  0:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-12 23:51 [Bonding-devel][PATCH]Zero Copy Transmit Support (Update) Radheka Godse
2004-11-12  0:00 ` David S. Miller [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-11-18 19:02 Godse, Radheka
2004-11-12 21:31 Godse, Radheka
2004-11-12 21:20 ` David S. Miller
2004-11-12 21:56   ` Jay Vosburgh
2004-11-12 21:49     ` David S. Miller
2004-11-12 22:20       ` Jay Vosburgh
2004-11-12 22:24         ` David S. Miller

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=20041111160021.5c586095.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=bonding-devel@lists.sourceforge.net \
    --cc=ctindel@users.sourceforge.net \
    --cc=fubar@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=radheka.godse@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox