Re: [PATCH][RFC 23/23]: Support for zero-copy TCP transmit of userspace data

From: James Bottomley
Date: Fri Dec 12 2008 - 14:38:11 EST


On Fri, 2008-12-12 at 22:25 +0300, Vladislav Bolkhovitin wrote:
> > One thing that leaps immediately to mind is that you could isolate this
> > to the net layer by putting it in skb_frag_struct. However, such a move
> > would require a proper API for this in net ...
>
> To have net_priv analog in skb was the first idea I was tried. But I
> quickly gave up, because it would required that all the pages in each
> skb_frag_struct be from the same originator, i.e. with the same
> net_priv. It is unpractical to change all the operations with skb's to
> forbid merging them, if they have different net_priv. There are too many
> such places in very not obvious code pieces.

Actually, I said carry in skb_frag_struct not skb ... that allows for
merging of skbs with different page sources. The API changes would have
to allow setting at this level.

> > right now it looks like
> > you're using the struct page addition to carry this information from
> > SCSI to net, which is a bit of a layering violation.
>
> I don't think there is any layering violation here. Just lower layer
> notifies upper layer that transmission of a page has finished. It's done
> a bit not straightforward, but still basically the same as, for
> instance, on_free_cmd() callbacks which SCST core uses to notify target
> drivers and dev handlers that the corresponding command is about to be
> freed, so they can free associated with it data as well.

The way you transmit the information you want notification is done by a
private tag in struct page, so you're carrying the information on an
object that belongs to neither layer ... that's the violation. It's
essentially an extension of the net API that goes via the mm layer.

James


--
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/