From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: "Tan, Jianfeng" <jianfeng.tan@intel.com>,
aconole@redhat.com, sodey@sonusnet.com,
yuanhan.liu@linux.intel.com, thomas.monjalon@6wind.com,
dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v3 7/9] net/virtio: Add MTU feature support
Date: Fri, 7 Apr 2017 18:40:39 +0200 [thread overview]
Message-ID: <1e0af6da-cb01-fb91-c0b0-efa08ebd9f21@redhat.com> (raw)
In-Reply-To: <5f8ae5f8-22a5-ef95-058d-6865b154bef0@intel.com>
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
next prev parent reply other threads:[~2017-04-07 16:40 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 14:28 [dpdk-dev] [PATCH 0/7] virtio/vhost: " Maxime Coquelin
2017-02-13 14:28 ` [dpdk-dev] [PATCH 1/7] vhost: Enable VIRTIO_NET_F_MTU feature Maxime Coquelin
2017-02-13 14:28 ` [dpdk-dev] [PATCH 2/7] vhost: vhost-user: Add MTU protocol feature support Maxime Coquelin
2017-02-13 14:28 ` [dpdk-dev] [PATCH 3/7] vhost: Add new ready status flag Maxime Coquelin
2017-02-13 14:28 ` [dpdk-dev] [PATCH 4/7] vhost: Add API to get/set MTU value Maxime Coquelin
2017-02-13 14:28 ` [dpdk-dev] [PATCH 5/7] net/vhost: Implement mtu_set callback Maxime Coquelin
2017-02-13 14:28 ` [dpdk-dev] [PATCH 6/7] net/virtio: Add MTU feature support Maxime Coquelin
2017-02-16 19:31 ` Aaron Conole
2017-02-16 21:17 ` Maxime Coquelin
2017-02-13 14:28 ` [dpdk-dev] [PATCH 7/7] app/testpmd: print MTU value in show port info Maxime Coquelin
2017-02-23 7:10 ` [dpdk-dev] [PATCH 0/7] virtio/vhost: Add MTU feature support Yuanhan Liu
2017-03-01 7:44 ` Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 " Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 1/7] vhost: Enable VIRTIO_NET_F_MTU feature Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 2/7] vhost: vhost-user: Add MTU protocol feature support Maxime Coquelin
2017-03-08 2:31 ` Yuanhan Liu
2017-03-12 10:24 ` Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 3/7] vhost: Add new ready status flag Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 4/7] vhost: Add API to get MTU value Maxime Coquelin
2017-03-08 2:45 ` Yuanhan Liu
2017-03-12 10:23 ` Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 5/7] net/vhost: Fill rte_eth_dev's MTU property Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 6/7] net/virtio: Add MTU feature support Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 7/7] app/testpmd: print MTU value in show port info Maxime Coquelin
2017-03-07 21:57 ` [dpdk-dev] [PATCH v2 0/7] virtio/vhost: Add MTU feature support Thomas Monjalon
2017-03-12 10:00 ` Maxime Coquelin
2017-03-12 16:33 ` [dpdk-dev] [PATCH v3 0/9] " Maxime Coquelin
2017-03-12 16:33 ` [dpdk-dev] [PATCH v3 1/9] vhost: Enable VIRTIO_NET_F_MTU feature Maxime Coquelin
2017-03-12 16:33 ` [dpdk-dev] [PATCH v3 2/9] vhost: vhost-user: Add MTU protocol feature support Maxime Coquelin
2017-03-12 16:34 ` [dpdk-dev] [PATCH v3 3/9] vhost: Add new ready status flag Maxime Coquelin
2017-03-12 16:34 ` [dpdk-dev] [PATCH v3 4/9] vhost: Add API to get MTU value Maxime Coquelin
2017-03-16 8:00 ` Yuanhan Liu
2017-03-16 11:37 ` Maxime Coquelin
2017-03-17 5:32 ` Yuanhan Liu
2017-03-17 9:59 ` Maxime Coquelin
2017-03-20 8:42 ` Yuanhan Liu
2017-03-12 16:34 ` [dpdk-dev] [PATCH v3 5/9] vhost: export " Maxime Coquelin
2017-03-12 16:34 ` [dpdk-dev] [PATCH v3 6/9] net/vhost: Fill rte_eth_dev's MTU property Maxime Coquelin
2017-03-12 16:34 ` [dpdk-dev] [PATCH v3 7/9] net/virtio: Add MTU feature support Maxime Coquelin
2017-04-05 4:52 ` Tan, Jianfeng
2017-04-05 7:11 ` Maxime Coquelin
2017-04-05 9:42 ` Tan, Jianfeng
2017-04-05 13:54 ` Maxime Coquelin
2017-04-05 14:50 ` Tan, Jianfeng
2017-04-07 16:40 ` Maxime Coquelin [this message]
2017-04-10 6:48 ` Tan, Jianfeng
2017-03-12 16:34 ` [dpdk-dev] [PATCH v3 8/9] doc: announce Virtio and Vhost MTU support Maxime Coquelin
2017-03-12 16:34 ` [dpdk-dev] [PATCH v3 9/9] app/testpmd: print MTU value in show port info Maxime Coquelin
2017-03-22 8:58 ` [dpdk-dev] [PATCH v3 0/9] virtio/vhost: Add MTU feature support Yuanhan Liu
2017-03-22 9:03 ` Maxime Coquelin
2017-03-28 5:39 ` Yao, Lei A
2017-03-30 11:34 ` Maxime Coquelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1e0af6da-cb01-fb91-c0b0-efa08ebd9f21@redhat.com \
--to=maxime.coquelin@redhat.com \
--cc=aconole@redhat.com \
--cc=dev@dpdk.org \
--cc=jianfeng.tan@intel.com \
--cc=sodey@sonusnet.com \
--cc=thomas.monjalon@6wind.com \
--cc=yuanhan.liu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).