-----Original Message----- > Date: Fri, 10 Aug 2018 07:37:21 +0000 > From: "Xing, Beilei" <beilei.x...@intel.com> > To: Jerin Jacob <jerin.ja...@caviumnetworks.com> > CC: "Lu, Wenzhuo" <wenzhuo...@intel.com>, "Wu, Jingjing" > <jingjing...@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.ja...@caviumnetworks.com] > > Sent: Friday, August 10, 2018 11:45 AM > > To: Xing, Beilei <beilei.x...@intel.com> > > Cc: Lu, Wenzhuo <wenzhuo...@intel.com>; Wu, Jingjing > > <jingjing...@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.x...@intel.com> > > > To: wenzhuo...@intel.com, jingjing...@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.x...@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.
