Re: [PATCH 5/5] skbuff: skb_segment: orphan frags before copying

From: Michael S. Tsirkin
Date: Mon Mar 10 2014 - 18:30:52 EST


On Tue, Mar 11, 2014 at 06:12:23AM +0800, Herbert Xu wrote:
> On Tue, Mar 11, 2014 at 12:07:17AM +0200, Michael S. Tsirkin wrote:
> >
> > Once one skb completes the callback is invoked and userspace
> > reuses this buffer for something else.
> > At that point it's too late to do the copy.
>
> OK, would it be possible to delay the callback until all generated
> skbs are completed?

Hmm this won't be easy since devices can complete them in any order.
See below for some ideas.

> > > IOW if we pass along SKBTX_SHARED_FRAG will it work?
> >
> > I don't see how would SKBTX_SHARED_FRAG help with this at all.
> > That only works for pages gifted to kernel by e.g. vmsplice
> > that aren't reused by userspace.
>
> Sorry cut-n-paste error, I meant SKBTX_DEV_ZEROCOPY.
>
> Cheers,

Ah ok. Well we'd need to reference-count them somehow.
Maybe skb_get and stick the pointer in ubuf callback for the
new skbs, make ubuf callback kfree_skb?
Not sure if that's too much memory ...

I also worry a bit that we'll lose the success flag value which is used
to disable zero copy on OOM errors more aggressively.

How about we do the simple thing as the first step and try to optimize
as a separate patch on top?

> --
> Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/