DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>
Cc: Moti Haimovsky <motih@mellanox.com>,
	dev@dpdk.org, shahafs@mellanox.com, ferruh.yigit@intel.com
Subject: Re: [dpdk-dev] [PATCH] app/testpmd: do not enable Rx offloads by default
Date: Thu, 25 Jan 2018 10:04:11 +0100	[thread overview]
Message-ID: <60691740.PPs9Gye6m2@xps> (raw)
In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093B715D7A@shsmsx102.ccr.corp.intel.com>

25/01/2018 02:11, Lu, Wenzhuo:
> > --- a/app/test-pmd/testpmd.c
> > +++ b/app/test-pmd/testpmd.c
> > @@ -305,9 +305,7 @@ struct fwd_engine * fwd_engines[] = {
> >   */
> >  struct rte_eth_rxmode rx_mode = {
> >  	.max_rx_pkt_len = ETHER_MAX_LEN, /**< Default maximum frame
> > length. */
> > -	.offloads = (DEV_RX_OFFLOAD_VLAN_FILTER |
> > -		     DEV_RX_OFFLOAD_VLAN_STRIP |
> > -		     DEV_RX_OFFLOAD_CRC_STRIP),
> > +	.offloads = 0,
> 
> Change the default behavior may trigger other problems. I think TX offload could be a good reference. Get the capability and check what's supported first, then ignore the not supported functions with printing a warning but not block anything...

I agree that we should check the capabilities before requesting an offload.
But I disagree on another point: we should not enable an offload if the
user did not request it explicitly. It makes things unclear.
This is a testing tool, it should be close to the ethdev API behavior.

Why these offload flags are silently enabled?

  reply	other threads:[~2018-01-25  9:04 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 [this message]
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
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=60691740.PPs9Gye6m2@xps \
    --to=thomas@monjalon.net \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=motih@mellanox.com \
    --cc=shahafs@mellanox.com \
    --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).