All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	virtualization@lists.osdl.org, ak@suse.de, jeff@garzik.org,
	jmorris@namei.org, netdev@vger.kernel.org
Subject: Re: [patch 7/9] lguest: the net driver
Date: Wed, 09 May 2007 21:55:25 +1000	[thread overview]
Message-ID: <1178711725.7286.82.camel@localhost.localdomain> (raw)
In-Reply-To: <E1HljA6-0001E4-00@gondolin.me.apana.org.au>

On Wed, 2007-05-09 at 20:12 +1000, Herbert Xu wrote:
> akpm@linux-foundation.org wrote:
> >
> > +       if (desc->features & LGUEST_NET_F_NOCSUM)
> > +               dev->features |= NETIF_F_NO_CSUM;
> 
> Any reason why you're using NO_CSUM here instead of HW_CSUM?
> Practically there is no difference but NO_CSUM could be treated
> differently in future and I'm not sure whether such changes would
> be desirable in this driver (i.e., not even generating a partial
> checksum).

Hi Herbert,

	NO_CSUM because it really doesn't need a checksum.  The
LGUEST_NET_F_NOCSUM is only set for local inter-guest networking.  If
some guest were to route the packets outside the machine, this would be
an issue, though ("don't do that").

> Also, there doesn't seem to be any passing of metadata to the
> backend which means that neither NO_CSUM/HW_CSUM can work if
> somebody needs to look at the checksum field.  You could use
> IP_CSUM if you do the same hack on the backend that Xen does.
> Otherwise you'll have to make do with no checksum offload at all.

Yeah, definitely good future work.  This is far simpler: external-facing
networks don't get marked with the LGUEST_NET_F_NOCSUM but set.

KVM is going to have a paravirt network driver too: it'd be nice to
share code here.

> I think you'd also need a change_mtu function if the SG feature
> is going to be of some use since the default Ethernet one limits
> the MTU to 1500.

Indeed, that would be a new feature, and is certainly a consideration
for more efficient inter-guest networking.  However, I consider that
somewhat cheating: it's nice to know that 1500 doesn't suck too hard.

Remember, "Features kill puppies!" 8)

Thanks,
Rusty.


  reply	other threads:[~2007-05-09 11:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-09  9:51 [patch 7/9] lguest: the net driver akpm
2007-05-09 10:12 ` Herbert Xu
2007-05-09 10:12   ` Herbert Xu
2007-05-09 11:55   ` Rusty Russell [this message]
2007-05-09 12:00     ` Herbert Xu
2007-05-09 12:13       ` Rusty Russell
2007-05-09 12:28 ` Jeff Garzik
2007-05-09 12:42   ` Andi Kleen
2007-05-09 15:14   ` Rusty Russell
2007-05-09 21:09     ` Christoph Hellwig
2007-05-10  5:33     ` Jeff Garzik
2007-05-10 10:12       ` 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=1178711725.7286.82.camel@localhost.localdomain \
    --to=rusty@rustcorp.com.au \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jeff@garzik.org \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=virtualization@lists.osdl.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 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.