Re: [Qemu-devel] [PATCH V3 05/10] net/net.c: Add vnet header length to SocketReadState

[Jason Wang <jasowang@redhat.com>]

On 2017年05月09日 14:59, Zhang Chen wrote:
>
>
> On 05/09/2017 01:36 PM, Jason Wang wrote:
>>
>>
>> On 2017年05月09日 12:03, Zhang Chen wrote:
>>>
>>>
>>> On 05/09/2017 10:40 AM, Jason Wang wrote:
>>>>
>>>>
>>>> On 2017年05月08日 11:47, Zhang Chen wrote:
>>>>>
>>>>>
>>>>> On 05/03/2017 06:42 PM, Jason Wang wrote:
>>>>>>
>>>>>>
>>>>>> On 2017年05月03日 11:43, Zhang Chen wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 05/02/2017 12:53 PM, Jason Wang wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2017年04月28日 17:47, Zhang Chen wrote:
>>>>>>>>> Address Jason Wang's comments add vnet header length to 
>>>>>>>>> SocketReadState.
>>>>>>>>
>>>>>>>> Instead of saying this, you can add "Suggested-by: Jason Wang 
>>>>>>>> <jasowang@redhat.com>" above your sign-off.
>>>>>>>
>>>>>>> OK.
>>>>>>>
>>>>>>>>
>>>>>>>>> So we change net_fill_rstate() to read
>>>>>>>>> struct  {int size; int vnet_hdr_len; const uint8_t buf[];}.
>>>>>>>>
>>>>>>>> This makes me thinking about the backward compatibility. I 
>>>>>>>> think we'd better try to keep it as much as possible. E.g how 
>>>>>>>> about pack vnet_hdr_len into higher bits of size?
>>>>>>>>
>>>>>>>
>>>>>>> Do you means split uint32_t size to uint16_t size and uint16_t 
>>>>>>> vnet_hdr_len ?
>>>>>>> If yes, we also can't keep compatibility with old version.
>>>>>>> Old code send a uint32_t size, we read it as uint16_t size is 
>>>>>>> always wrong.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Zhang Chen
>>>>>>
>>>>>> Consider it's unlikely to send or receive packet >= 64K, we can 
>>>>>> reuse higher bits (e.g highest 8 bits). Then we can still read 
>>>>>> uint32_t and then check its highest 8 bits. If it was zero, we 
>>>>>> know vnet header is zero, if not it could be read as vnet header 
>>>>>> length.
>>>>>
>>>>> I got your point, but in this way, packet size must < 64K, if size 
>>>>> >=64K we still can't maintain the backward compatibility,
>>>>> For the packet sender that didn't know the potential packet size 
>>>>> limit, I think we should make code explicitly declared like
>>>>> currently code. Otherwise we will make other people confused and 
>>>>> make code difficult to maintain.
>>>>>
>>>>> Thanks
>>>>> Zhang Chen
>>>>>
>>>>
>>>> Yes, this is an possible issue in the future. Rethink about this, 
>>>> what if we just compare vnet header? Is there any issue of doing 
>>>> this? (Sorry, I remember this is a reason, but forget now).
>>>
>>> Yes, we can compare all packet with vnet header, the compare 
>>> performance is very low. but we can't parse raw packet to 
>>> tcp/udp/icmp packet, because we didn't know the vnet_hdr_len as the 
>>> offset.
>>>
>>> Thanks
>>> Zhang Chen
>>
>> Aha, so I think it's time to use the new format but:
>>
>> - probably need a new option to enable this support for filter
>
> Do you means we should add the new option for every filter object like 
> that:
> Now:
> -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0
> Feature:
> -object 
> filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0,has_vnet_hdr_len=on
>
> And colo-compare also need this option to get the vnet_hdr_len.

Yes, and you can use make it short like "vnet_hdr".

>
>
>> - let's don't touch socket backend, and make it still can work with 
>> filters whose vnet_hder is off
>
> OK, Maybe we can add a new variable in net_fill_rstate().

Right.

Thanks

>
> Thanks
> Zhang Chen
>
>>
>> Thanks
>>
>>>
>>>>
>>>> Thanks
>>>>
>>>>
>>>> .
>>>>
>>>
>>
>>
>>
>> .
>>
>