Add a new structure for skb buffer from external.
in [Kernel]
|
From: Herbert Xu on 18 Jun 2010 03:50 On Fri, Jun 18, 2010 at 03:14:18PM +0800, Xin, Xiaohui wrote: > > 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? There is no reason why the napi_gro_frags can't be used by any driver that supports receiving data into pages. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert(a)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 linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael S. Tsirkin on 20 Jun 2010 06:20 On Fri, Jun 18, 2010 at 03:14:18PM +0800, Xin, Xiaohui wrote: > >-----Original Message----- > >From: Herbert Xu [mailto:herbert(a)gondor.apana.org.au] > >Sent: Friday, June 18, 2010 1:59 PM > >To: Xin, Xiaohui > >Cc: Stephen Hemminger; netdev(a)vger.kernel.org; kvm(a)vger.kernel.org; > >linux-kernel(a)vger.kernel.org; mst(a)redhat.com; mingo(a)elte.hu; davem(a)davemloft.net; > >jdike(a)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~} <herbert(a)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 linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Herbert Xu on 20 Jun 2010 06:40 On Sun, Jun 20, 2010 at 01:06:32PM +0300, Michael S. Tsirkin wrote: > > Changing the guest virtio to match the backend is a problem, > this breaks migration etc. As long as it's done in a backwards compatible way it should be fine. It's just like migrating from a backend that supports TSO to one that doesn't. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert(a)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 linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael S. Tsirkin on 20 Jun 2010 06:50 On Sun, Jun 20, 2010 at 08:32:35PM +1000, Herbert Xu wrote: > On Sun, Jun 20, 2010 at 01:06:32PM +0300, Michael S. Tsirkin wrote: > > > > Changing the guest virtio to match the backend is a problem, > > this breaks migration etc. > > As long as it's done in a backwards compatible way it should be > fine. Possibly, but to me the need to do this implies that we'll need another change with different hardware at the backend. > It's just like migrating from a backend that supports TSO > to one that doesn't. > > Cheers, Exactly. We don't support such migration. > -- > Visit Openswan at http://www.openswan.org/ > Email: Herbert Xu ~{PmV>HI~} <herbert(a)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 linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Herbert Xu on 20 Jun 2010 07:10
On Sun, Jun 20, 2010 at 01:39:09PM +0300, Michael S. Tsirkin wrote: > > > It's just like migrating from a backend that supports TSO > > to one that doesn't. > > Exactly. We don't support such migration. Well that's something that has to be addressed in the virtio_net. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert(a)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 linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |