[dpdk-dev] [PATCH v2] bond: inherit maximum rx packet length

[Declan Doherty]

CC'ing follow up conversation which I accidentally took of list.

-------- Forwarded Message --------
Subject: Re: [dpdk-dev] [PATCH] bond: inherit maximum rx packet length
Date: Wed, 4 May 2016 14:11:53 -0400
From: Eric Kinzie <ehkinzie at gmail.com>
To: Declan Doherty <declan.doherty at intel.com>

On Wed May 04 14:53:26 +0100 2016, Declan Doherty wrote:
 > On 29/04/16 22:36, Eric Kinzie wrote:
 > >On Tue Apr 26 11:51:53 +0100 2016, Declan Doherty wrote:
 > >>On 14/04/16 18:23, Eric Kinzie wrote:
 > >>>  Instead of a hard-coded maximum receive length, allow the bond 
interface
 > >>>  to inherit this limit from the first slave added.  This allows
 > >>>  an application that uses jumbo frames to pass realistic values to
 > >>>  rte_eth_dev_configure without causing an error.
 > >>>
 > >>>Signed-off-by: Eric Kinzie <ehkinzie at gmail.com>
 > >>>---
 > >>...
 > >>>
 > >>
 > >>Hey Eric, just one small thing, I think it probably makes sense to
 > >>return the max rx pktlen for all slaves, so as we add each slave
 > >>just check if that the slave being value is larger than the current
 > >>value.
 > >>
 > >>@@ -385,6 +389,10 @@ __eth_bond_slave_add_lock_free(uint8_t
 > >>bonded_port_id, uint8_t slave_port_id)
 > >>                internals->tx_offload_capa &= dev_info.tx_offload_capa;
 > >>                internals->flow_type_rss_offloads &=
 > >>dev_info.flow_type_rss_offloads;
 > >>
 > >>+               /* If new slave's max rx packet size is larger than
 > >>current value then override */
 > >>+               if (dev_info.max_rx_pktlen > internals->max_rx_pktlen)
 > >>+                       internals->max_rx_pktlen = 
dev_info.max_rx_pktlen;
 > >>+
 > >>
 > >>Declan
 > >
 > >Declan, I sent an updated patch but now release that I mis-read your
 > >comments.  Is it a good idea to change the value once it's been set?
 > >My patch now refuses to add a slave with a pktlen value that's smaller
 > >than that of the first slave.
 > >
 > >Eric
 > >
 >
 > Hey Eric,
 >
 > actually I think you're right, we can't change the value dynamically
 > once the bonded device has been configured (maybe gating on
 > start/stop would be sufficient), but I think we shouldn't explicitly
 > gate on the first slave added, as we may be bonding multiple slaves
 > each of which could have different max_rx_pktlens. Prior to calling
 > dev_configure on the bonded device it should be possible to add any
 > slave with any max_rx_pktlen and inherit the minimum value, but once
 > the bonded device has been configured we would refuse a slave with a
 > max_rx_pktlen value which is smaller than the current value. I think
 > this should then satisfy that all slaves meet the minimum
 > requirements published by the bonded device?
 >

Hi, Declan.  I think that would work out ok.  I'll write something to
that effect and send another version of the patch.