On Fri, Feb 26, 2021 at 3:21 AM Ferruh Yigit <ferruh.yi...@intel.com> wrote:
>
> On 2/26/2021 6:43 AM, Andrew Rybchenko wrote:
> > On 2/25/21 9:25 PM, Ferruh Yigit wrote:
> >> On 2/22/2021 7:18 PM, Ajit Khaparde wrote:
> >>> Add support for forced ethernet speed setting.
> >>> Currently testpmd tries to configure the Ethernet port in autoneg mode.
> >>> It is not possible to set the Ethernet port to a specific speed while
> >>> starting testpmd. In some cases capability to configure a forced speed
> >>> for the Ethernet port during initialization may be necessary. This patch
> >>> tries to add this support.
> >>>
> >>> The patch assumes full duplex setting and does not attempt to change
> >>> that.
> >>> So speeds like 10M, 100M are not configurable using this method.
> >>>
> >>> The command line to configure a forced speed of 10G:
> >>> dpdk-testpmd -c 0xff -- -i --eth-link-speed 10000
> >>>
> >>> The command line to configure a forced speed of 50G:
> >>> dpdk-testpmd -c 0xff -- -i --eth-link-speed 50000
> >>>
> >>> Signed-off-by: Ajit Khaparde <ajit.khapa...@broadcom.com>
> >>> ---
> >>> app/test-pmd/parameters.c | 42 +++++++++++++++++++++++++++
> >>> app/test-pmd/testpmd.c | 4 +++
> >>> app/test-pmd/testpmd.h | 1 +
> >>> doc/guides/testpmd_app_ug/run_app.rst | 11 +++++++
> >>> 4 files changed, 58 insertions(+)
> >>
> >> Can you also update the release notes to document the new parameter?
> >>
> >>>
> >>> diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
> >>> index c8acd5d1b7..e10f7d38fb 100644
> >>> --- a/app/test-pmd/parameters.c
> >>> +++ b/app/test-pmd/parameters.c
> >>> @@ -224,6 +224,7 @@ usage(char* progname)
> >>> printf(" --hairpin-mode=0xXX: bitmask set the hairpin port
> >>> mode.\n "
> >>> " 0x10 - explicit Tx rule, 0x02 - hairpin ports paired\n"
> >>> " 0x01 - hairpin ports loop, 0x00 - hairpin port
> >>> self\n");
> >>> + printf(" --eth-link-speed: forced link speed.\n");
> >>> }
> >>> #ifdef RTE_LIB_CMDLINE
> >>> @@ -485,6 +486,41 @@ parse_event_printing_config(const char *optarg,
> >>> int enable)
> >>> return 0;
> >>> }
> >>> +static int
> >>> +parse_link_speed(int n)
> >>> +{
> >>> + uint32_t speed;
> >>> +
> >>> + switch (n) {
> >>
> >> OK to not support "10M, 100M", not sure if anybody really uses them, but
> >> what do you think checking them and return an error?
> >>
> >>> + case 1000:
> >>> + speed = ETH_LINK_SPEED_1G;
> >>> + break;
> >>> + case 10000:
> >>> + speed = ETH_LINK_SPEED_10G;
> >>> + break;
> >>> + case 25000:
> >>> + speed = ETH_LINK_SPEED_25G;
> >>> + break;
> >>> + case 40000:
> >>> + speed = ETH_LINK_SPEED_40G;
> >>> + break;
> >>> + case 50000:
> >>> + speed = ETH_LINK_SPEED_50G;
> >>> + break;
> >>> + case 100000:
> >>> + speed = ETH_LINK_SPEED_100G;
> >>> + break;
> >>> + case 200000:
> >>> + speed = ETH_LINK_SPEED_200G;
> >>> + break;
> >>> + default:
> >>> + speed = ETH_LINK_SPEED_AUTONEG;
> >>> + break;
> >>
> >> Isn't this function to set a fixed link speed, why falling back to autoneg?
> >>
> >> Also shouldn't this function set 'ETH_LINK_SPEED_FIXED' too?
> >
> > It should. Previous time I've tried to fix corresponding
> > bug in CLI commands, it ended up with rollback because
> > of Intel drivers do not handle it correctly.
I can set the ETH_LINK_SPEED_FIXED bit while setting the fixed speed.
> >
> > See "app/testpmd: set fixed flag for exact link speed" and
> > corresponding revert.
I took a look at the patch.
Looks like we were setting ETH_LINK_SPEED_FIXED in
parse_and_check_speed_duplex(). Which is an existing function.
I am adding the fixed speed capability during application init itself.
So it is a little different than what was done earlier.
I will send a v2 with the suggestions I got so far.
> >
>
> Thanks for the reminder Andrew, you have a good memory :)
> For reference:
> http://inbox.dpdk.org/dev/20190507100928.pOyue5JiSaPL-NSHiueAU3HlgisgF9bYynJGpTjyvMw@z/
>
> It seems that patch reverted with the pressure of the release, what do you
> think
> applying it again while we have enough time to fix the PMDs before release?
>
> From previous discussions, long term actions listed as:
> "
> 1) Implement 'fixed' link speed support in the missing drivers.
> 2) Send a new version of the testpmd patch with a "fixed" argument, so that we
> can support all three above
> "
>
> Not sure having (2) explicitly is required, we have already "auto" speed, not
> having it implies the fixed speed.
> So we can just re-apply your old patch.
I think that's a good idea. If there are any issues with the drivers,
there is time to address them.
