On Wed, 2007-05-09 at 20:12 +1000, Herbert Xu wrote:
> [EMAIL PROTECTED] 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.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
