DPDK patches and discussions
 help / color / mirror / Atom feed
From: Shahaf Shuler <shahafs@mellanox.com>
To: Thomas Monjalon <thomas@monjalon.net>,
	"Lu, Wenzhuo" <wenzhuo.lu@intel.com>
Cc: Mordechay Haimovsky <motih@mellanox.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] [PATCH] app/testpmd: do not enable Rx offloads by default
Date: Sat, 27 Jan 2018 18:14:35 +0000	[thread overview]
Message-ID: <VI1PR05MB3149816D5FA97C08D7895128C3E70@VI1PR05MB3149.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <4518250.zEhSojeenl@xps>

Friday, January 26, 2018 10:36 AM, Thomas Monjalon:
> 26/01/2018 09:06, Lu, Wenzhuo:
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > 26/01/2018 08:30, Lu, Wenzhuo:
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > 25/01/2018 02:11, Lu, Wenzhuo:
> > > > > Why these offload flags are silently enabled?
> > > >
> > > > I don't think it's silently. It's a global configuration. In this
> > > > case, testpmd is
> > > the user, it does request it explicitly. If it's not so explicit,
> > > maybe we can consider moving all the configuration to a specific
> configure file.
> > > > Talking about why it's enabled by default. Hard to figure out the history.
> > > To my opinion, the original designer wants to simulate the common case.
> > >
> > > Please do not justify a design mistake by history.
> > >
> > > This is a test tool, so we don't care about the common case.
> > > A test tool should not try to guess the best configuration.
> > > Only the user should decide the configuration to apply, and the
> > > default should be empty, as the API is.
> >
> > I see the divergence. You think testpmd is a tool, so it should be white
> paper as the tool users may suppose it is.
> > I think testpmd is an example to let the APP developers know how to use
> DPDK. So any pre-configuration is acceptable.

If so, then what this patch shows that it is not such a good example to application writers. 
Application should not set offloads that are not supported by the PMD. Pre-configuration is OK, but adjustment is a must according to the PMD caps. 
I think that many PMD have a wrong behavior due to it. They are forced to silently drop un-supported offload configuration (to enable testpmd to run on top of them).
This will end up, for example, in application which expects to have the VLAN tag in the mbuf (because the configuration passed successfully), while in fact it will be always in the packet headers. 

I didn't change it on my series because I wanted to convert the application "as is" from the old to the new offloads API,  however I do think a change is needed here.

 
> 
> Ah ah ah :)
> No
> Examples are in examples/ directory.

  reply	other threads:[~2018-01-27 18:14 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-23  8:11 Moti Haimovsky
2018-01-25  1:11 ` Lu, Wenzhuo
2018-01-25  9:04   ` Thomas Monjalon
2018-01-25 16:01     ` Stephen Hemminger
2018-01-26  7:31       ` Lu, Wenzhuo
2018-01-26  7:49         ` Thomas Monjalon
2018-01-26  7:30     ` Lu, Wenzhuo
2018-01-26  7:48       ` Thomas Monjalon
2018-01-26  8:06         ` Lu, Wenzhuo
2018-01-26  8:35           ` Thomas Monjalon
2018-01-27 18:14             ` Shahaf Shuler [this message]
2018-01-29 11:33 ` [dpdk-dev] [PATCH v2] " Moti Haimovsky
2018-01-29 11:52   ` Thomas Monjalon
2018-01-30  8:44   ` [dpdk-dev] [PATCH v3] " Moti Haimovsky
2018-01-30  9:00     ` [dpdk-dev] [PATCH v4] " Moti Haimovsky
2018-01-31  3:16       ` Lu, Wenzhuo
2018-01-31 11:55       ` [dpdk-dev] [PATCH v5] " Moti Haimovsky
2018-01-31 16:59         ` [dpdk-dev] [PATCH v6] app/testpmd: no Rx or Tx " Moti Haimovsky
2018-01-31 17:19           ` Thomas Monjalon
2018-01-31 17:32           ` [dpdk-dev] [PATCH v7] app/testpmd: removed preconf Rx VLAN offloads Moti Haimovsky
2018-01-31 21:09             ` Thomas Monjalon

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=VI1PR05MB3149816D5FA97C08D7895128C3E70@VI1PR05MB3149.eurprd05.prod.outlook.com \
    --to=shahafs@mellanox.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=motih@mellanox.com \
    --cc=thomas@monjalon.net \
    --cc=wenzhuo.lu@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).