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.kavan...@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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
