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