[ovs-dev] [PATCH] netdev-dpdk: Add Jumbo Frame Support.

[Qiu, Michael]

On 2015/11/18 23:13, Kavanagh, Mark B wrote:
>> On 2015/11/18 1:25, Flavio Leitner wrote:
>>> On Wed, Nov 11, 2015 at 03:06:02PM +0000, Mark Kavanagh wrote:
>>>> Add support for Jumbo Frames to DPDK-enabled port types,
>>>> using single-segment-mbufs.
>>>>
>>>> Using this approach, the amount of memory allocated for each mbuf
>>>> to store frame data is increased to a value greater than 1518B
>>>> (typical Ethernet maximum frame length). The increased space
>>>> available in the mbuf means that an entire Jumbo Frame can be carried
>>>> in a single mbuf, as opposed to partitioning it across multiple mbuf
>>>> segments.
>>>>
>>>> The amount of space allocated to each mbuf to hold frame data is
>>>> defined by the user at compile time; if this frame length is not a
>>>> multiple of the DPDK NIC driver's minimum Rx buffer length, the frame
>>>> length is rounded up to the closest value that is.
>>>>
>>>> Signed-off-by: Mark Kavanagh <mark.b.kavanagh at intel.com>
>>>> ---
>>>>  INSTALL.DPDK.md   |   67 ++++++++++++++++++++-
>>>>  lib/netdev-dpdk.c |  176 ++++++++++++++++++++++++++++++++++++++++++-----------
>>>>  2 files changed, 207 insertions(+), 36 deletions(-)
>>>>
>>>> diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md
>>>> index 96b686c..9a30f88 100644
>>>> --- a/INSTALL.DPDK.md
>>>> +++ b/INSTALL.DPDK.md
>>>> @@ -859,10 +859,70 @@ by adding the following string:
>>>>  to <interface> sections of all network devices used by DPDK. Parameter 'N'
>>>>  determines how many queues can be used by the guest.
>>>>
>>>> +
>>>> +Jumbo Frames
>>>> +------------
>>>> +
>>>> +Support for Jumbo Frames may be enabled at compile-time for DPDK-type ports.
>>> It seems this could be dynamic and proportional to the MTU being used
>>> by the port and not a compile-time option which depends on the NIC
>>> hardware specs. Perhaps I am missing something.
>> It make sense.
>>
>> And this patch really solve a big issue that when I transmit 1400 packet
>> size, ovs-vsvitchd will return a "Bus error", although 1400 should not
>> be a Jumbo frame.
>>
> Hi Michael,
>
> Thanks for your feedback; I'm glad to hear that the patch solved that issue for you - I'm curious as to why you experience the Bus error for 1400B packet though.

Finally, I find out that the root cause is the ovs has an issue with
init mbuf, ovs required buf_len 0x700, only set it in mbuf, and dpdk
need to know it in rte_pktmbuf_pool_init(), but ovs do nothing in it,
and you patch happend to fix that.

Thanks,
Michael
>
>> Mark, could it be an option when start vswitchd with dpdk, thus when
>> users try to using Jumbo Frame, it will not need to re-compile ovs, just
>> an advise :)
>>
> Agreed - I had intended to implement this functionality further down the line, depending on how this patch was received. I'll add a runtime flag in v2.
>
>> What's more, we could config it in run time, just like we dynamically
>> config the queue numbers, but this has a lot work to do, it could be a
>> further feature.
> Do you mean the 'other_config: n-dpdk-rxqs' field in the Open_vSwitch table?
>
> I'm not sure how amenable a solution like this would be to the maintainers, seeing as there is already an 'MTU' field present in the 'Interfaces' table. Ben/Pravin - any thoughts as to supporting a separate MTU field for DPDK interfaces?
>
> Thanks,
> Mark
>
>> Thanks,
>> Michael
>>> Thanks,
>>> fbl
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev at openvswitch.org
>>> http://openvswitch.org/mailman/listinfo/dev
>>>
>