Re: [Xen-devel] netback grant copying issues

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Sep 07, 2015 at 09:03:12AM -0600, Jan Beulich wrote:
> >>> On 07.09.15 at 16:47, <wei.liu2@xxxxxxxxxx> wrote:
> > On Fri, Sep 04, 2015 at 03:27:42AM -0600, Jan Beulich wrote:
> >> Ian, Wei,
> >> 
> >> I seem to be seeing two issues in the grant copy handling of netback,
> >> solely from code inspection:
> >> 
> >> 1) Shouldn't MAX_GRANT_COPY_OPS, to take care of the copying
> >> the header may require, be
> >> ((MAX_SKB_FRAGS + 1) * XEN_NETIF_RX_RING_SIZE)?
> >> 
> > 
> > Not sure what you mean by "header". I take it you mean SKB itself? We do
> > need to use grant copy data inside SKB (not in frag list) to frontend.
> 
> Yes - with "header" is mean everything up to skb_headlen(skb).
> 
> > It sounds plausible that there is some sort of miscounting, just that no
> > SKB is seen to be so broken to trigger that.
> 
> Why "broken"?
> 

Broken because I think that's going to introduce some performance
regression. But I see why "broken" is a bad description. Let's say, a
bit "extreme".

> > With that in mind, even MAX_SKB_FRAGS + 1 is not enough. It would be
> > MAX_SKB_FRAGS + 64K / PAGE_SIZE, i.e. we count the most extreme
> > situation that we have 63K data in SKB, and 1 byte in each frag.
> 
> No, every component (head + every frag) can contribute
> exactly one copy operation to a RX ring slot (larger heads, just
> like larger frags) would get copied into multiple RX ring slots.
> 

I think you misunderstand copy_op slot vs RX ring slot.  The limitation
rs for copy_op slots, not RX ring slots. Note that multiplication of
XEN_NETIF_RX_RING_SIZE.

The skb header data len is not limited to one 4K page (4K because that's
what xen grant table interface supports), netback will break skb header
data into multiple copy_op slots.

Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel