From: Mark McLoughlin <markmc@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: netdev <netdev@vger.kernel.org>,
virtualization <virtualization@lists.linux-foundation.org>,
Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH] virtio_net: large tx MTU support
Date: Fri, 28 Nov 2008 09:29:55 +0000 [thread overview]
Message-ID: <1227864595.3643.13.camel@blaa> (raw)
In-Reply-To: <200811281052.33474.rusty@rustcorp.com.au>
On Fri, 2008-11-28 at 10:52 +1030, Rusty Russell wrote:
> On Friday 28 November 2008 00:27:05 Mark McLoughlin wrote:
> > Hi Rusty,
> >
> > On Thu, 2008-11-27 at 23:00 +1030, Rusty Russell wrote:
> > > On Thursday 27 November 2008 00:28:11 Mark McLoughlin wrote:
> > > > We don't really have a max tx packet size limit, so allow configuring
> > > > the device with up to 64k tx MTU.
> > >
> > > Hi Mark,
> > >
> > > Just one comment: maybe we should be conservative and maybe limit to 1500
> > > if the host doesn't offer any of the GSO or MRG_RXBUF features?
> >
> > That was actually what I was going to do until I thought about it a bit
> > more and discussed it with Herbert.
> >
> > The virtio_net MTU only affects the transmit path, so there shouldn't be
> > any issue with a host that doesn't support those features.
>
> Not quite what I meant.
Well, you did mention MRG_RXBUF :-)
> A minimal host can reasonably expect ethernet-fitting packets. If it
> supports GSO of course it must handle larger ones.
I think this is orthogonal to GSO - e.g. a host may support GSO even if
it can only physically transmit 1500 byte frames.
MTU configuration is commonly a trial and error thing, so we're better
off allowing larger MTU sizes in cases where the host might not support
it rather than disallowing it in cases where the host can support it.
> Otherwise we should add YA feature bit or even a max-mtu field.
If e.g. we allowed physical device assignment via virtio, then the MTU
would be limited to the MTU supported by the physical device. In that
case it might make sense to add a max-mtu field or similar, but IMHO
it's fine to allow larger MTU sizes in the mean time.
Cheers,
Mark.
next prev parent reply other threads:[~2008-11-28 9:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 13:58 [PATCH] virtio_net: large tx MTU support Mark McLoughlin
2008-11-26 23:28 ` David Miller
2008-11-27 12:30 ` Rusty Russell
2008-11-27 13:57 ` Mark McLoughlin
2008-11-28 0:22 ` Rusty Russell
2008-11-28 9:29 ` Mark McLoughlin [this message]
2008-12-01 4:02 ` Rusty Russell
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=1227864595.3643.13.camel@blaa \
--to=markmc@redhat.com \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.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).