On Tue, Sep 24, 2024 at 3:59 PM Damodharam Ammepalli wrote: > > On Sun, Sep 22, 2024 at 10:02 AM Ferruh Yigit wrote: > > > > On 9/4/2024 6:50 PM, Damodharam Ammepalli wrote: > > > Update the eth_dev_ops structure with new function vectors > > > to get, get capabilities and set ethernet link speed lanes. > > > Update the testpmd to provide required config and information > > > display infrastructure. > > > > > > The supporting ethernet controller driver will register callbacks > > > to avail link speed lanes config and get services. This lanes > > > configuration is applicable only when the nic is forced to fixed > > > speeds. In Autonegiation mode, the hardware automatically > > > negotiates the number of lanes. > > > > > > These are the new commands. > > > > > > testpmd> show port 0 speed_lanes capabilities > > > > > > Supported speeds Valid lanes > > > ----------------------------------- > > > 10 Gbps 1 > > > 25 Gbps 1 > > > 40 Gbps 4 > > > 50 Gbps 1 2 > > > 100 Gbps 1 2 4 > > > 200 Gbps 2 4 > > > 400 Gbps 4 8 > > > testpmd> > > > > > > testpmd> > > > testpmd> port stop 0 > > > testpmd> port config 0 speed_lanes 4 > > > testpmd> port config 0 speed 200000 duplex full > > > testpmd> port start 0 > > > testpmd> > > > testpmd> show port info 0 > > > > > > ********************* Infos for port 0 ********************* > > > MAC address: 14:23:F2:C3:BA:D2 > > > Device name: 0000:b1:00.0 > > > Driver name: net_bnxt > > > Firmware-version: 228.9.115.0 > > > Connect to socket: 2 > > > memory allocation on the socket: 2 > > > Link status: up > > > Link speed: 200 Gbps > > > Active Lanes: 4 > > > Link duplex: full-duplex > > > Autoneg status: Off > > > > > > Signed-off-by: Damodharam Ammepalli > > > --- > > > app/test-pmd/cmdline.c | 248 ++++++++++++++++++++++++++++++++++++- > > > app/test-pmd/config.c | 4 + > > > lib/ethdev/ethdev_driver.h | 91 ++++++++++++++ > > > lib/ethdev/rte_ethdev.c | 52 ++++++++ > > > lib/ethdev/rte_ethdev.h | 95 ++++++++++++++ > > > lib/ethdev/version.map | 5 + > > > 6 files changed, 494 insertions(+), 1 deletion(-) > > > > > > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c > > > index b7759e38a8..643102032e 100644 > > > --- a/app/test-pmd/cmdline.c > > > +++ b/app/test-pmd/cmdline.c > > > @@ -284,6 +284,9 @@ static void cmd_help_long_parsed(void *parsed_result, > > > > > > "dump_log_types\n" > > > " Dumps the log level for all the dpdk modules\n\n" > > > + > > > + "show port (port_id) speed_lanes capabilities" > > > + " Show speed lanes capabilities of a port.\n\n" > > > ); > > > } > > > > > > @@ -823,6 +826,9 @@ static void cmd_help_long_parsed(void *parsed_result, > > > "port config (port_id) txq (queue_id) affinity (value)\n" > > > " Map a Tx queue with an aggregated port " > > > "of the DPDK port\n\n" > > > + > > > + "port config (port_id|all) speed_lanes (0|1|4|8)\n" > > > > > > > This help string, and the implementation, implies there has to be fixed > > lane values, like 1, 4, 8. Why not leave this part to the capability > > reporting, and not limit (and worry) those values in the command, so > > from command's perspective it can be only . > > > > ok, will update the help string to > > > > + " Set number of lanes for all ports or port_id for a forced speed\n\n" > > > ); > > > } > > > > > > @@ -1560,6 +1566,244 @@ static cmdline_parse_inst_t cmd_config_speed_specific = { > > > }, > > > }; > > > > > > +static int > > > +parse_speed_lanes_cfg(portid_t pid, uint32_t lanes) > > > +{ > > > + int ret; > > > + > > > + ret = rte_eth_speed_lanes_set(pid, lanes); > > > > > > > As a sample application usage, I think it is better if it gets the > > capability and verify that 'lanes' is withing the capability and later > > set it, what do you think? > > > > <...> > > Makes sense, will try out and get back to you soon. > I guess a similar comment was discussed in the past, slipped my mind to mention in my last response. These are the reasons for this logic. - same lane number can be supported by any speed (eg: 4 Lanes supported in 100,200,400 etc) so, which speed row should app check against, since the user has not configured fixed speed yet. If the link is already up in AN mode, this lane config doesn't have any significance. - one approach would be to validate lanes in parse_and_check_speed_duplex(), but in this case, the app should already have non-default lanes value. We also need to consider the case, if the user wants default lanes. - In the ethtool, the driver does the validation of the speed x lanes combo. Tried to match similar behaviour. Let me know your thoughts. > > > > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h> index > > 548fada1c7..9444e0a836 100644 > > > --- a/lib/ethdev/rte_ethdev.h > > > +++ b/lib/ethdev/rte_ethdev.h > > > @@ -357,6 +357,27 @@ struct rte_eth_link { > > > #define RTE_ETH_LINK_MAX_STR_LEN 40 /**< Max length of default link string. */ > > > /**@}*/ > > > > > > +/** > > > + * Constants used to indicate the possible link speed lanes of an ethdev port. > > > + */ > > > +#define RTE_ETH_SPEED_LANE_UNKNOWN 0 /**< speed lanes unsupported mode or default */ > > > +#define RTE_ETH_SPEED_LANE_1 1 /**< Link speed lane 1 */ > > > +#define RTE_ETH_SPEED_LANE_2 2 /**< Link speed lanes 2 */ > > > +#define RTE_ETH_SPEED_LANE_4 4 /**< Link speed lanes 4 */ > > > +#define RTE_ETH_SPEED_LANE_8 8 /**< Link speed lanes 8 */ > > > + > > > +/* Translate from link speed lanes to speed lanes capa */ > > > +#define RTE_ETH_SPEED_LANES_TO_CAPA(x) RTE_BIT32(x) > > > + > > > +/* This macro indicates link speed lanes capa mask */ > > > +#define RTE_ETH_SPEED_LANES_CAPA_MASK(x) RTE_BIT32(RTE_ETH_SPEED_ ## x) > > > + > > > > > > > I am not clear why we need these macros, why not use lane number as > > unsigned integer, instead of macro (RTE_ETH_SPEED_LANE_2), it will be > > more flexible. > > > > ok, I can replace the macros with unsigned integers > > > Probably all we need is 'RTE_ETH_SPEED_LANES_TO_CAPA' one to use as > > helper in drivers. > > Again not sure about the ..CAPA_MASK one, does it actually produce a > > mask value? > > > > > once replacing the LANE_xx to unsigned integers, then I don't need x_CAPA_MASK. > In the driver, I can call RTE_32(lane number) while populating the table. > EG: > > { RTE_ETH_SPEED_NUM_100G, RTE_ETH_SPEED_LANES_CAPA_MASK(LANE_1) | > RTE_ETH_SPEED_LANES_CAPA_MASK(LANE_2) | > RTE_ETH_SPEED_LANES_CAPA_MASK(LANE_4) }, > will become > > { RTE_ETH_SPEED_NUM_100G, RTE_BIT32(1) | > RTE_BIT32(2) | > RTE_BIT32(4) }, -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.