From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
Stephen Hemminger <stephen@networkplumber.org>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>
Cc: Jerin Jacob <jerinjacobk@gmail.com>,
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>,
nd <nd@arm.com>,
"Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>,
"Walsh, Conor" <conor.walsh@intel.com>
Subject: Re: [dpdk-dev] L3fwd mode in testpmd
Date: Wed, 28 Apr 2021 11:00:25 +0000 [thread overview]
Message-ID: <DM6PR11MB4491DB9D3DFD36C775BFFA449A409@DM6PR11MB4491.namprd11.prod.outlook.com> (raw)
In-Reply-To: <DBAPR08MB58148FF4B4BD900B74398DEC98419@DBAPR08MB5814.eurprd08.prod.outlook.com>
> <snip>
>
> >
> > > >
> > > > On Tue, 27 Apr 2021 10:50:20 +0100
> > > > Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> > > >
> > > > > Agree that it may help testing to have l3fwd support on the testpmd.
> > > > >
> > > > > Two concerns,
> > > > > 1) Testpmd already too complex.
> > > > > 2) Code duplication.
> > > > >
> > > > > For 1), if the l3fwd can be implemented in testpmd as new,
> > > > > independent forwarding mode, without touching rest of the testpmd,
> > > > > I think it can be
> > > > OK.
> > > > >
> > > > > 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?
> > > >
> > > > The original purpose of l3fwd seems to be getting lost here.
> > > > It was intended as an example, not a complete test or real life application.
> > > The issue is, this app has become an industry standard for performance
> > comparison between platforms (whether we like it or not).
> > > But, it
> > > does not have a whole lot of debugging capabilities.
> >
> > Ok, could you list what exactly you think is missed?
> > If we are talking about extra stats, then I still think it is probably easier to add
> > it into l3fwd, then pull whole l3fwd code into test-pmd.
> In stats it is missing hardware, software stats, burst stats.
> From run time configuration capability, it is missing burst size, rx/tx queue depth, number of queues we can assign to a core.
AFAIK l3fwd is quite flexible in rx queues to cores assignments, so not sure what else do you have in mind here.
About other things - in general I am ok for adding these extra functionality into l3fwd.
I don't see any major issues here.
I think it will be less effort then pulling l3fwd into test-pmd.
>
> >
> > > I think adding a L3fwd mode to testpmd will be helpful to keep the
> > > sample application simpler.
> >
> > Hmm, not sure how these 2 things are linked...
> > Why let say adding fib-fwd into test-pmd will help to decrease l3fwd code
> > complexity?
> From my perspective, L3fwd example application should showcase how to use DPDK, various packet processing models in DPDK. Anyone
> new to DPDK should be able to take this code and start creating their application.
> However, this application has LPM, Exact match and FIB. I am not sure how Exact Match and FIB modes help the user.
About exact match - routing decisions are not always made on des tip address.
Sometimes you need to look at whole addrs+proto+ports tuple.
Exact match provides example for such case.
I also think it would be really good to add ACL mode into l3fwd too (merge l3fwd and l3fd-acl apps into one).
> I suggest removing LPM from L3fwd example application as FIB is added (or vice versa).
AFAIK, as a stretch goal LPM library has to be replaced with FIB one.
Recently FIB was added into l3fwd, so I suppose deprecating and removing LPM mode here
is natural next step (if there would be no performance impact off-course).
CC-ing to Vladimir (FIB maintainer) and Conor to learn their opinions.
next prev parent reply other threads:[~2021-04-28 11:00 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-10 18:31 Honnappa Nagarahalli
2021-03-11 6:41 ` Jerin Jacob
2021-03-11 15:18 ` Honnappa Nagarahalli
2021-03-11 15:46 ` Thomas Monjalon
2021-03-11 16:00 ` Honnappa Nagarahalli
2021-03-31 20:35 ` Kathleen Capella
2021-03-31 21:17 ` Jerin Jacob
2021-04-01 0:20 ` Honnappa Nagarahalli
2021-04-01 4:38 ` Jerin Jacob
2021-04-24 0:26 ` Honnappa Nagarahalli
2021-04-26 9:44 ` Jerin Jacob
2021-04-26 17:47 ` Stephen Hemminger
2021-04-26 20:46 ` Honnappa Nagarahalli
2021-04-27 9:39 ` Andrew Rybchenko
2021-04-27 9:50 ` Ferruh Yigit
2021-04-27 9:57 ` Ananyev, Konstantin
2021-04-27 11:11 ` Thomas Monjalon
2021-04-27 11:32 ` Bruce Richardson
2021-04-27 23:26 ` Honnappa Nagarahalli
2021-04-27 23:17 ` Honnappa Nagarahalli
2021-04-28 10:48 ` Bruce Richardson
2021-04-28 11:04 ` Stanisław Kardach
2021-04-28 11:19 ` Thomas Monjalon
2021-04-28 21:44 ` Honnappa Nagarahalli
2021-04-29 7:49 ` Stanislaw Kardach
2021-04-29 8:31 ` Ananyev, Konstantin
2021-04-29 10:39 ` Stanislaw Kardach
2021-04-29 11:47 ` Ananyev, Konstantin
2021-04-29 11:53 ` Stanislaw Kardach
2021-04-30 11:28 ` Ananyev, Konstantin
2021-08-02 15:07 ` Dharmik Thakkar
2021-04-28 11:17 ` Thomas Monjalon
2021-04-28 10:59 ` Ananyev, Konstantin
2021-04-28 22:10 ` Honnappa Nagarahalli
2021-04-27 16:01 ` Stephen Hemminger
2021-04-27 20:20 ` Honnappa Nagarahalli
2021-04-27 22:23 ` Ananyev, Konstantin
2021-04-27 23:11 ` Honnappa Nagarahalli
2021-04-28 11:00 ` Ananyev, Konstantin [this message]
2021-04-26 20:32 ` Honnappa Nagarahalli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM6PR11MB4491DB9D3DFD36C775BFFA449A409@DM6PR11MB4491.namprd11.prod.outlook.com \
--to=konstantin.ananyev@intel.com \
--cc=Dharmik.Thakkar@arm.com \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=Kathleen.Capella@arm.com \
--cc=Ruifeng.Wang@arm.com \
--cc=bruce.richardson@intel.com \
--cc=conor.walsh@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=jerinj@marvell.com \
--cc=jerinjacobk@gmail.com \
--cc=nd@arm.com \
--cc=stephen@networkplumber.org \
--cc=sthemmin@microsoft.com \
--cc=thomas@monjalon.net \
--cc=vladimir.medvedkin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).