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

[Flavio Leitner]

On Wed, Nov 18, 2015 at 03:03:42PM +0000, Kavanagh, Mark B 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.
> >
> 
> Hi Flavio - thanks for your feedback.
> 
> Just to clarify, when you say 'dynamic', I presume that you mean
> that the MTU can be specified at runtime. Bearing this in mind, is
> the behavior that you have in mind that:
> 	- the MTU for each DPDK port should be specified when the port is added to a bridge?
> 	- and the granularity at which MTUs are assigned to DPDK-type
> 	ports should be on a per-port basis, rather than the (admittedly)
> 	coarse-grained 'one-for-all' approach implemented here?

It should be per-port basis like we have for non-DPDK cases and the
bridge might reconfigure itself to maintain the low common value on
all ports.  Look at the update_mtu() function.

> It's worth noting that due to the fact that DPDK ports are outside
> the reach of the Linux kernel, their MTU can't be changed using
> standard tools, such as 'ifconfig', 'ip link', etc. Furthermore, the
> OVS 'Interface' table's 'MTU' attribute cannot currently be set
> programmatically, outside of the aforementioned tools. In this way,
> the MTU of DPDK ports is always limited in how dynamic it can be,
> hence, once set, the MTU for a DPDK port is (currently) immutable.

I have the same understanding.  However, a hardcoded option isn't a
good solution if we want to support other MTU sizes.  Think about
Debian/Ubuntu/Fedora distros having to provide few different packages
with special values that might not even be the one needed.


> I'm not quite sure if I follow the second part of your comment
> regarding proportionality to the port's MTU - could you elaborate a
> bit more on this?

Dynamic in terms of hardcoded versus run-time option.  The
proportional part refers to the size of the allocated buffers.
We should be able to change those at run-time.

Does that make sense?

fbl