Re: [dpdk-dev] L3fwd mode in testpmd

From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	Jerin Jacob <jerinjacobk@gmail.com>
Cc: Kathleen Capella <Kathleen.Capella@arm.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Dharmik Thakkar <Dharmik.Thakkar@arm.com>,
	Ruifeng Wang <Ruifeng.Wang@arm.com>,
	"david.marchand@redhat.com" <david.marchand@redhat.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
	Stephen Hemminger <sthemmin@microsoft.com>, nd <nd@arm.com>,
	Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	nd <nd@arm.com>
Subject: Re: [dpdk-dev] L3fwd mode in testpmd
Date: Wed, 28 Apr 2021 22:10:56 +0000	[thread overview]
Message-ID: <DBAPR08MB5814B05E1D05D4A8A1DF9EEA98409@DBAPR08MB5814.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <DM6PR11MB44919BA0829F3B36C10419389A409@DM6PR11MB4491.namprd11.prod.outlook.com>

<snip>

> 
> >
> > >
> > > In fact, l3fwd is also quite big and complex:
> > > $ wc -l examples/l3fwd/*.[h,c] |grep total
> > >   6969 total
> > >
> > > Plus it will introduce extra dependencies (fib, lpm, hash, might-be
> > > acl?) I am not sure it is a good idea to pull all these complexities into test-
> pmd.
> > I do not suggest pulling all these in. In our case, I see that the ask is only on
> LPM. I am open to hearing what others see as the requirement.
> 
> Ok, but l3fwd forwarding model is quite different from current PMD one
> (egress queue selection, TX packets buffering, etc.).
> I suppose you'll need to pull all that too from l3fwd?
We will send an RFC to show what it looks like.

> 
> >
> > > I can't imagine that l3fwd app need ability to configure each and
> > > every PMD parameter.
> > > From my experience in l3fwd most of cycles are spent not in PMD
> > > itself, but in actual packet processing: header parsing and
> > > checking, classification, routing table lookup, etc.
> > During our work, we had to experiment with burst size, rx/tx queue
> > depths along with other PMD specific configuration parameters. The packet
> processing code remains the same and there is not much to optimize.
> 
> I think burst-size and rx/tx queue size can be added into l3fwd as new config
> parameters.
> Doesn't look like a major issue to me.
> PMD specific parameters could be a problem... anything particular you plan
> to use?
We are talking about debugging the performance problem which needs all the flexibility possible.

> 
> > >
> > > > Not sure how to address 2), also lets say we want to add new
> > > > feature to l3fwd, where it should go, to the sample or to the testpmd?
> > L3fwd example will remain as the example. We have to duplicate the
> > code into testpmd. If L3fwd example is changed, it needs to be changed in
> testpmd as well.
> 
> Usually code duplication is not a good sign.
> I understand that sometimes it is unavoidable, but why we have to do it
> here?