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
