| 
    
 [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 5/6] xen-netback: coalesce slots before copying
 On 25/03/13 11:08, Wei Liu wrote:
> This patch tries to coalesce tx requests when constructing grant copy
> structures. It enables netback to deal with situation when frontend's
> MAX_SKB_FRAGS is larger than backend's MAX_SKB_FRAGS.
> 
> It defines max_skb_slots, which is a estimation of the maximum number of slots
> a guest can send, anything bigger than that is considered malicious. Now it is
> set to 20, which should be enough to accommodate Linux (16 to 19).
This maximum needs to be defined as part of the protocol and added to
the interface header.
> Also change variable name from "frags" to "slots" in netbk_count_requests.
I think this renaming should have been done as a separate patch.
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -47,11 +47,26 @@
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/page.h>
>  
> +/*
> + * This is an estimation of the maximum possible frags a SKB might
> + * have, anything larger than this is considered malicious. Typically
> + * Linux has 16 to 19.
> + */
Do you mean "max possible /slots/" a packet might have?
> @@ -968,48 +987,114 @@ static struct gnttab_copy 
> *xen_netbk_get_requests(struct xen_netbk *netbk,
[...]
> +                             /* Poison these fields, corresponding
> +                              * fields for head tx req will be set
> +                              * to correct values after the loop.
> +                              */
> +                             netbk->mmap_pages[pending_idx] = (void *)(~0UL);
> +                             pending_tx_info[pending_idx].head =
> +                                     INVALID_PENDING_RING_IDX;
Do you need to poison both values?
> +
> +                             if (unlikely(!first)) {
This isn't unlikely is it?
> +                                     first = &pending_tx_info[pending_idx];
> +                                     start_idx = index;
> +                                     head_idx = pending_idx;
> +                             }
Instead of setting first here why not move the code below here?
> +             first->req.offset = 0;
> +             first->req.size = dst_offset;
> +             first->head = start_idx;
> +             set_page_ext(page, netbk, head_idx);
> +             netbk->mmap_pages[head_idx] = page;
> +             frag_set_pending_idx(&frags[shinfo->nr_frags], head_idx);
> @@ -1548,13 +1649,34 @@ static void xen_netbk_idx_release(struct xen_netbk 
> *netbk, u16 pending_idx,
[...]
> +             /* Setting any number other than
> +              * INVALID_PENDING_RING_IDX indicates this slot is
> +              * starting a new packet / ending a previous packet.
> +              */
> +             pending_tx_info->head = 0;
This doesn't look needed.  It will be initialized again when reusing t
his pending_tx_info again, right?
> +             index = pending_index(netbk->pending_prod++);
> +             netbk->pending_ring[index] = netbk->pending_ring[info_idx];
> +
> +             xenvif_put(vif);
> +
> +             peek = netbk->pending_ring[pending_index(++head)];
> +
> +     } while (netbk->pending_tx_info[peek].head
> +              == INVALID_PENDING_RING_IDX);
>  
>       netbk->mmap_pages[pending_idx]->mapping = 0;
>       put_page(netbk->mmap_pages[pending_idx]);
David
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
 
 
  | 
  
![]()  | 
            
         Lists.xenproject.org is hosted with RackSpace, monitoring our  |