[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090915133151.GA28431@gondor.apana.org.au>
Date: Tue, 15 Sep 2009 08:31:51 -0500
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Or Gerlitz <ogerlitz@...taire.com>
Cc: "Michael S. Tsirkin" <mst@...hat.com>,
David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH RFC] tun: export underlying socket
On Tue, Sep 15, 2009 at 04:02:35PM +0300, Or Gerlitz wrote:
>
> Yes, I am aware that GSO can take action and so software segmentation is / can be done when the HW isn't capable of doing so (and I assume the same can go for checksum). I assume that by "we provide" you mean the core networking code, correct? in what level? I assume its not the TCP one, since this is not applicable a tun/bridge scheme. Simper example would be the vm nic MTU... with vhost attached directly to a nic with packet socket you can learn/control it all, where when tun/bridge is used, how can you tell?
You handle it the same way as how you've always done with MTUs,
ensure that the MTU is set to the maximum required by all the
guests. If that means the guests cannot use jumboframes then
that's what you're stuck with.
This is the whole reason why TSO exists in the first place.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists