Re: [Xen-devel] [PATCH 2/2] netif: define XEN_NETIF_NR_SLOTS_MIN in public header

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-04-30 at 18:06 +0100, Wei Liu wrote:
> Xen network protocol has implicit dependency on MAX_SKB_FRAGS. In order to
> remove dependency on MAX_SKB_FRAGS, we derive a constant from historical
> MAX_SKB_FRAGS for future reference.
> 
> Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>

Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

> ---
>  xen/include/public/io/netif.h |   18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
> index ccde53b..9664998 100644
> --- a/xen/include/public/io/netif.h
> +++ b/xen/include/public/io/netif.h
> @@ -31,6 +31,24 @@
>  #include "../grant_table.h"
>  
>  /*
> + * Older implementation of Xen network frontend / backend has an
> + * implicit dependency on the MAX_SKB_FRAGS as the maximum number of
> + * ring slots a skb can use. Netfront / netback may not work as
> + * expected when frontend and backend have different MAX_SKB_FRAGS.
> + *
> + * A better approach is to add mechanism for netfront / netback to
> + * negotiate this value. However we cannot fix all possible
> + * frontends, so we need to define a value which states the minimum
> + * slots backend must support.
> + *
> + * The minimum value derives from older Linux kernel's MAX_SKB_FRAGS
> + * (18), which is proved to work with most frontends. Any new backend
> + * which doesn't negotiate with frontend should expect frontend to
> + * send a valid packet using slots up to this value.
> + */
> +#define XEN_NETIF_NR_SLOTS_MIN 18
> +
> +/*
>   * Notifications after enqueuing any type of message should be conditional on
>   * the appropriate req_event or rsp_event field in the shared ring.
>   * If the client sends notification for rx requests then it should specify



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