On Wed, Feb 1, 2023 at 4:35 PM Thomas Monjalon <tho...@monjalon.net> wrote: > > 01/02/2023 11:58, Andrew Rybchenko: > > On 2/1/23 13:48, Jerin Jacob wrote: > > > On Wed, Feb 1, 2023 at 2:59 PM Andrew Rybchenko > > > <andrew.rybche...@oktetlabs.ru> wrote: > > >> Frankly speaking I don't understand why default value is so > > >> important if we have a way to change it. Reasons should be > > >> really strong to change existing defaults. > > > > > > The only reason is, typically testpmd will be used performance > > > benchmarking as an industry standard. It is difficult to tell/educate > > > the QA or customers > > > that, "BTW if you need to get better performance add more flag to > > > testpmd command line". > > I disagree. > When you do performance benchmark, you tune settings accordingly.
IMO, We tune the system resources like queue depth not the disabling features for raw performance. queue depth etc people know to tune so it is obvious. What is not obvious is, testpmd only negotiated some features by default.I am not using that feature, hence I need to explicitly disable it. > > > > To make that worst, only some PMD needs to give the additional > > > parameter to get better number. > > > And also, testpmd usage will be treated as application modeling. > > > > > > Since this feature only used on sfc and cnxk driver, What is the > > > situation with sfc driver? > > > Keeping it as negotiated and not use the feature, will impact the per > > > core performance of sfc or > > > is it just PCI bandwidth thing which really dont show any difference in > > > testpmd? > > > > Yes, sfc could run faster if no Rx metadata are negotiated. So, > > it is better to negotiate nothing by default. But it is always > > painful to change defaults. You need to explain that now you > > need to negotiate Rx metadata to use mark, flag and tunnel offloads. > > Yes, it will be required on sfc and cnxk only. > > As an sfc maintainer I don't mind to change testpmd defaults. > > If we change testpmd defaults to "do nothing", > then we should disable MBUF_FAST_FREE as well. if you see MBUF_FAST_FREE, it does nothing. Actually, !MBUF_FAST_FREE is doing more work. > >
