[dpdk-dev] [PATCH v3 7/9] net/virtio: Add MTU feature support

[Maxime Coquelin]

Hi Jianfeng,

On 04/05/2017 04:50 PM, Tan, Jianfeng wrote:
>
>
> On 4/5/2017 9:54 PM, Maxime Coquelin wrote:
>>
>>
>> On 04/05/2017 11:42 AM, Tan, Jianfeng wrote:
>>> Hi Maxime,
>>>
>>> Thank you for replying.
>>>
>>> On 4/5/2017 3:11 PM, Maxime Coquelin wrote:
>>>> Hi Jianfeng,
>>>>
>>>> On 04/05/2017 06:52 AM, Tan, Jianfeng wrote:
>>>>> Hi Maxime,
>>>>>
>>>>> Have some confusion about this feature. Please help confirm.
>>>>>
>>>>> (1) With this feature, we only support to advertise MTU value which is
>>>>> defined by QEMU to frontend and backend driver separately. (2) But it
>>>>> does not allow frontend driver to set a different MTU to QEMU and then
>>>>> to vhost backend.
>>>>>
>>>>> Correct?
>>>>> If it's correct, why not MTU works like (2)?
>>>>
>>>> Because idea is that the hosts advertises the maximum MTU value it
>>>> supports. The frontend driver is free to use a smaller value. The goal
>>>> of this change is to make possible to set a uniform MTU value across
>>>> the infrastructure, the management tools giving a hint to the guests on
>>>> the MTU value it should use.
>>>
>>> Based on that MTU is the maximum packet size that can be sent instead of
>>> that can be received:
>>> (1) Why vhost (as a device) does not drop any packets which are longer
>>> than MTU when dequeue()?
>> That's a good point.
>> As when MTU value is negotiated, the guest agrees not to send larger
>> packets. But we cannot trust the guest, so vhost needs to check the
>> packet length.
>>
>>> (2) See some NICs also use MTU to calculate maximum packet size that can
>>> be received, like ixgbe, i40e, shall we also do that?
>> Can you give me some pointers to the code?
>
> Please refer ixgbe_dev_mtu_set(), and i40e_dev_mtu_set().

Thanks. Yes, we could also do that.

I can send a patch for this and another one to check the size of the
packet respects negotiated MTU value. Or maybe you want to do this?

Regards,
Maxime