Hi,
On Sun, Sep 03, 2000 at 07:29:56PM +0200, Ingo Molnar wrote:
>
> On Sun, 3 Sep 2000, Andi Kleen wrote:
>
> > I did the same for fragment RX some months ago (simple fragment lists
> > that were copy-checksummed to user space). Overall it is probably
> > better to use a kiovec, because that can be more easily used in nfsd
> > and sendfile.
>
> the basic fragment type introduced by the TUX changes is a 'struct
> skb_frag', which has csum, size, *page, page_offset, frag_done, *data and
> *private fields - this is more than normal kiovecs offer. But i think
> kiovecs can be extended to do all this (if Stephen & everybody else
> agrees), i just didnt want to touch it for the time being.
I don't want to extend kiobufs for that sort of thing, since the
entire point of having kiobufs is to have a uniform container with
which to pass information between different kernel components. If you
need more data, you'd do something like the SGI kiobuf-based block IO
stack does --- use a dedicated struct request, but use a pointer to a
kiobuf as the data location within that request struct.
In principle I'd think it would be a lot easier to add a kiovec
pointer to an skbuff than to extend kiobufs to be suitable for the
networking stack (and we had a BOF on this at OLS --- it seemed quite
feasible).
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
