RE: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback

["Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>]

> > I think we can make the guest TX path work rather better by
> > putting the tx packet header off into a separate fragment and
> > placing it within one of a set of pages that are
> > 'permanently' mapped between the front and back ends. The
> > backend would not typically grant map the payload
> > fragment(s), but only do so if it catches a page fault trying
> > to access them.
> >
> > The way I'd do the 'permanent' mappings is to have a bit in
> > the grant reference passed across the ring that indicates
> > that the backend is free to leave the grant mapped. The bit
> > should be set whenever the grant entry is used (the front end
> > can't mix and match). The backend thus just needs to keep
> > track of which grant refs it has mapped via this permanent
> > scheme so that it can spot (valid) reuse, and clean up
> > afterwards. Since the front end will typically use a block of
> > grant refs for this purpose the backend code can be optimised
> > for a simple range check. The frontend is free to pack
> > multiple header fragments on to a page to save memory (rather
> > than using larger payload sized frags).
>
>   The way I did it was slightly different.
>   The shared pages used to store the packet headers are
>   mapped at driver initialization at the same time the
>   I/O ring is initialized (You can think of these pages
>   as an extension to the I/O ring and mapped and unmapped at
>   the same time). This shared header area
>   is divided into fixed size slots large enough to store all
>   packet headers (MAC/IP/TCP). Netfront copies the
>   header of the packet to a free slot on the shared header
>   buffer area and passes the offset of the header on the
>   first I/O ring request for the packet (instead of
>   passing a grant reference). Payload data are transferred
>   as additional requests on I/O ring using grant
>   references as usual. Netback assumes the first request
>   of all packets point to headers in the shared area and
>   copies the header into the main socket buffer data area.
>   Payload data (in additional I/O ring requests) are associated
>   with skb fragments but not mapped into dom0 memory
>   unless a page fault happens
>   (indicating that dom0 is trying to access that data).
>   If the packet is sent out on the wire, the payload is never
>   touched by the CPU (assuming no netfilter rules, etc...)
>   and no memory mapping is necessary.

Yep, the approach is similar, but I think having the 'permanent' grants
mechanism is probably a bit more flexible for managing the header
fragments.

It would be good if you could post your patch as it has relevance to
what Herbert is currently working on.

BTW: I'm pretty convinced its time to redefine the net ring format to
ensure each fragment has an id, flags, grant, offset and length fields.
Things are just getting messy with the current format.

Best,
Ian




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel