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

Tan, Jianfeng jianfeng.tan at intel.com
Wed Apr 5 16:50:54 CEST 2017



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,
Jianfeng


More information about the dev mailing list