On Fri, Jun 18, 2010 at 03:14:18PM +0800, Xin, Xiaohui wrote: > >-----Original Message----- > >From: Herbert Xu [mailto:herb...@gondor.apana.org.au] > >Sent: Friday, June 18, 2010 1:59 PM > >To: Xin, Xiaohui > >Cc: Stephen Hemminger; net...@vger.kernel.org; kvm@vger.kernel.org; > >linux-ker...@vger.kernel.org; m...@redhat.com; mi...@elte.hu; > >da...@davemloft.net; > >jd...@linux.intel.com; Rusty Russell > >Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from > >external. > > > >On Fri, Jun 18, 2010 at 01:26:49PM +0800, Xin, Xiaohui wrote: > >> > >> Herbert, > >> I have questions about the idea above: > >> 1) Since netdev_alloc_skb() is still there, and we only modify > >> alloc_page(), > >> then we don't need napi_gro_frags() any more, the driver's original > >> receiving > >> function is ok. Right? > > > >Well I was actually thinking about converting all drivers that > >need this to napi_gro_frags. But now that you mention it, yes > >we could still keep the old interface to minimise the work. > > > >> 2) Is napi_gro_frags() only suitable for TCP protocol packet? > >> I have done a small test for ixgbe driver to let it only allocate paged > >> buffers > >> and found kernel hangs when napi_gro_frags() receives an ARP packet. > > > >It should work with any packet. In fact, I'm pretty sure the > >other drivers (e.g., cxgb3) use that interface for all packets. > > > Thanks for the verification. By the way, does that mean that nearly all > drivers can use the > same napi_gro_frags() to receive buffers though currently each driver has > it's own receiving > function? > > >> 3) As I have mentioned above, with this idea, netdev_alloc_skb() will > >> allocate > >> as usual, the data pointed by skb->data will be copied into the first > >> guest buffer. > >> That means we should reserve sufficient room in guest buffer. For PS mode > >> supported driver (for example ixgbe), the room will be more than 128. > >> After 128bytes, > >> we will put the first frag data. Look into virtio-net.c the function > >> page_to_skb() > >> and receive_mergeable(), that means we should modify guest virtio-net > >> driver to > >> compute the offset as the parameter for skb_set_frag(). > >> > >> How do you think about this? Attached is a patch to how to modify the > >> guest driver. > >> I reserve 512 bytes as an example, and transfer the header len of the skb > >> in hdr->hdr_len. > > > >Expanding the buffer size to 512 bytes to accomodate PS mode > >looks reasonable to me. > > > >However, I don't think we should increase the copy threshold to > >512 bytes at the same time. I don't have any figures myself but > >I think if we are to make such a change it should be a separate > >one and come with supporting numbers. > > > Let me have a look to see if I can retain the copy threshold as 128 bytes > and copy the header data safely.
Changing the guest virtio to match the backend is a problem, this breaks migration etc. > >Cheers, > >-- > >Visit Openswan at http://www.openswan.org/ > >Email: Herbert Xu ~{PmV>HI~} <herb...@gondor.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 kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
