On Thu, 11 Feb 2016 02:55:43 +0000 Daniele Di Proietto <diproiet...@vmware.com> wrote:
> On 08/02/2016 03:23, "Kavanagh, Mark B" <mark.b.kavan...@intel.com> wrote: > > >> > >>Hi Mark, > >> > > > >Hi Daniele, > > > >Thanks for the review! Responses inline below. > > > >Cheers, > >Mark > > > >>This patch besides adding Jumbo Frame support also cleans up > >>the mbuf initialization (by changing the macros, adding > >>dpdk_buf_size, and rewriting __ovs_rte_pktmbuf_init), so thanks > >>for this. I think it makes sense to split the patch in two: > >>one that does the clenup, and one that allows configuring the > >>MTU. > > > >Okay, sounds good - I'll spin another version, splitting into a two patch > >set. > > Thanks! > > > > >> > >>I agree with Flavio's comments as well, more inline > >> > >>Thanks > >> > >>On 01/02/2016 02:18, "Mark Kavanagh" <mark.b.kavan...@intel.com> 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 dynamically by the user when adding a DPDK port to a bridge. > >>>If an MTU value is not supplied, or the user-supplied value is invalid, > >>>the MTU for the port defaults to standard Ethernet MTU (i.e. 1500B). > >>> > >>>Signed-off-by: Mark Kavanagh <mark.b.kavan...@intel.com> > >>>--- > >>> INSTALL.DPDK.md | 59 +++++++++- > >>> NEWS | 2 + > >>> lib/netdev-dpdk.c | 347 > >>>+++++++++++++++++++++++++++++++++++++++++------------- > >>> 3 files changed, 328 insertions(+), 80 deletions(-) > >>> > >>>diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md > >>>index 96b686c..64ccd15 100644 > >>>--- a/INSTALL.DPDK.md > >>>+++ b/INSTALL.DPDK.md > >>>@@ -859,10 +859,61 @@ 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 run-time for DPDK-type > >>>ports. > >>>+ > >>>+To avail of Jumbo Frame support, add the 'dpdk-mtu' option to the > >>>ovs-vsctl > >>>+'add-port' command-line, along with the required MTU for the port. > >>>+e.g. > >>>+ > >>>+ ``` > >>>+ ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk > >>>options:dpdk-mtu=9000 > >>>+ ``` > >>>+ > >>>+When Jumbo Frames are enabled, the size of a DPDK port's mbuf segments > >>>are > >>>+increased, such that a full Jumbo Frame may be accommodated inside a > >>>single > >>>+mbuf segment. Once set, the MTU for a DPDK port is immutable. > >> > >>Why is it immutable? > > > >I guess my rationale here is that an MTU change can't be triggered via > >OVS command-line, nor can it be triggered programmatically via DPDK > >(apart from an explicit call to rte_eth_dev_set_mtu). > >So, while technically it's possibly, from a user's point of view, there's > >no way to configure it, outside of modifying the code directly. > >If I've missed something here, please let me know. > > With > > ovs-vsctl set Interface options:dpdk-mtu=... > > you could change it at runtime. Have you considered that in this patch? > I guess it's ok to have it configurable only when the port is added for > now, > but we need to make sure that nothing bad happens if a user tries to change > it when it's running. > > Also, after talking with other people, I think that a better name for the > parameter might be 'mtu_request', and we might want to use it also for > kernel > ports (but that doesn't need to be done now). > I am not sure about that idea because if you think in other scenarios, we use the same way to set and to verify the MTU. So, having mtu-request and mtu seems to be counter intuitive for me, though it is better than dpdk-mtu. -- fbl _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
