Re: [dpdk-dev] [PATCH] app/testpmd: support bitmask for RSS and FDIR

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

-----Original Message-----
> Date: Fri, 10 Aug 2018 07:37:21 +0000
> From: "Xing, Beilei" <beilei.xing@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> CC: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>, "Wu, Jingjing"
>  <jingjing.wu@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
> Subject: RE: [dpdk-dev] [PATCH] app/testpmd: support bitmask for RSS and
>  FDIR
> 
> 
> Hi Jacob,

Hi Xing,

> 
> > -----Original Message-----
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > Sent: Friday, August 10, 2018 11:45 AM
> > To: Xing, Beilei <beilei.xing@intel.com>
> > Cc: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Wu, Jingjing
> > <jingjing.wu@intel.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] app/testpmd: support bitmask for RSS and
> > FDIR
> >
> > -----Original Message-----
> > > Date: Mon, 6 Aug 2018 13:45:35 +0800
> > > From: Beilei Xing <beilei.xing@intel.com>
> > > To: wenzhuo.lu@intel.com, jingjing.wu@intel.com
> > > CC: dev@dpdk.org
> > > Subject: [dpdk-dev] [PATCH] app/testpmd: support bitmask for RSS and
> > > FDIR
> > > X-Mailer: git-send-email 2.5.5
> > >
> > >
> > > This patch adds bitmask support for RSS, FDIR and FDIR flexible
> > > payload.
> > >
> > > Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> > > ---
> > >  app/test-pmd/cmdline.c                      | 199 +++++++++++++++++++++++++---
> > >  doc/guides/testpmd_app_ug/testpmd_funcs.rst |   8 +-
> > >  2 files changed, 187 insertions(+), 20 deletions(-)
> > >
> > > +#ifdef RTE_LIBRTE_I40E_PMD
> >
> >
> > How about moving all driver specific tests to driver/net/<driver>/?
> > I think, it wont scale if everyone starts adding their own driver specific tests
> > to testpmd.
> >
> > How about creating
> > #A generic string parser in testpmd?  something like, port config (port_id)
> > <driver name> ....
> > # and do driver_name to port_id lookup
> > # and introduce "test" or "self_test" ops in ethdev # and call "test" op on the
> > selected port_id
> >
> 
> Thanks for the comment, but if so, then will remove and redesign all existed commands. I think it can be discussed in another thread.

The new commands can fall in generic scheme. Existing ones can moved
after deprecation notice procedure etc.

Otherwise hook under rte_flow API, so we don't need the private API.