Re: Is: SKB_MAX_LEN bites again. Was: Re: bug disabling guest interface

[ANNIE LI <annie.li@oracle.com>]

On 2013-3-9 4:36, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 08, 2013 at 08:36:37PM +0100, Jacek Milewicz wrote:
>> Hi All
>>
>>> Is there any further information on a possible fix for this? Thoughts?
>>> Ideas? As it seems to be hitting multiple sites, I'd like to get it
>> fixed asap...
>>
>> There are 3 ways I can see this fixed:
>> - update guests so all have same MAX_SKB_FRAGS (that includes windows
>> drivers (windows drivers use 19 for MAX_SKB_FRAGS))
>> -add some sort of negotiation between host and guest
>> - change MAX_SKB_FRAGS to 19 to accommodate all guests
>>
>> Unfortunately first one requires changes to the guest and most don't have
>> that luxury. So the only way I see it could be fixed without breaking
>> compatibility even more  is
> Ugh. The negotiations between host and guest is probably the best
> choice. The issues you are going to hit are that you might need
> to redo the skbs to match what the frontend's max is.
>
> Annie, Wei, Ian - were there some RFC patches floating around
> for this?

Actually I did plan to do it, but failed to start it because of windows 
WHQL things.

Thanks
Annie
>
>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>> index 821c7f4..82de0f5 100644
>> --- a/include/linux/skbuff.h
>> +++ b/include/linux/skbuff.h
>> @@ -143,8 +143,8 @@ struct sk_buff;
>>    * Since GRO uses frags we allocate at least 16 regardless of page
>>    * size.
>>    */
>> -#if (65536/PAGE_SIZE + 1)<  16
>> -#define MAX_SKB_FRAGS 16UL
>> +#if (65536/PAGE_SIZE + 1)<  19
>> +#define MAX_SKB_FRAGS 19UL
>>   #else
>>   #define MAX_SKB_FRAGS (65536/PAGE_SIZE + 1)
>>   #endif
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>