netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rick Jones <rick.jones2@hp.com>
To: Ben Greear <greearb@candelatech.com>
Cc: netdev <netdev@vger.kernel.org>
Subject: Re: MTU and TCP transmit offload.
Date: Wed, 21 Sep 2011 15:11:56 -0700	[thread overview]
Message-ID: <4E7A612C.9090508@hp.com> (raw)
In-Reply-To: <4E7A51EE.8010403@candelatech.com>

On 09/21/2011 02:06 PM, Ben Greear wrote:
> We saw something interesting while doing some testing
> on 3.0.4.
>
> We configured 2 Ethernet NICs with standard 1500 MTU, and added
> a mac-vlan on each, with MTU of 300. The goal was to generate as
> many ~300 byte TCP packets as possible, for load testing purposes.
> We configured our tool to open sockets on the mac-vlans and send/receive
> TCP (IPv4) traffic.

Presumably one could instead set static PathMTU entries in the routing 
tables and accomplish the same thing as you did with the mac-vlans?

> This actually seems to work quite nicely, allowing user-space to
> do large writes (24k in our case), and it appears have lots of
> small packets on the wire. We still need to sniff with external
> system to verify this..but packets-per-second counters look good.
>
> Evidently this all works because macvlans know that the NIC
> can do TSO, and the '300' MTU is passed in the big packet
> given to the NIC.
>
> This got me thinking...at least for my purposes, it would be
> nice to have a per-socket 'MTU' setting. The idea is that
> you could ask the NIC to do the TSO at whatever 'mtu' you
> wanted, without having to resort to mac-vlans with artificially
> small MTU.
>
> So, is there any interest in supporting such a socket option?
>
> I can't think of any use besides TCP traffic load testing, but
> perhaps someone else can think of one? Or, is load-testing
> enough?

Isn't that covered by setsockopt() support for TCP_MAX_SEG?  With TSO 
what gets passed to the NIC isn't the MTU, but the connection's MSS 
derived (in part at least) from the MTU of the egress interface.  If one 
had made a setsockopt(TCP_MAX_SEG) call prior to the connect() or 
listen() call, presumably that would have influenced the MSS exchange at 
connection establishment.

rick jones

  reply	other threads:[~2011-09-21 22:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-21 21:06 MTU and TCP transmit offload Ben Greear
2011-09-21 22:11 ` Rick Jones [this message]
2011-09-21 22:16   ` Ben Greear
2011-09-21 23:42     ` Ben Greear
2011-09-21 23:58       ` Rick Jones

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=4E7A612C.9090508@hp.com \
    --to=rick.jones2@hp.com \
    --cc=greearb@candelatech.com \
    --cc=netdev@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).