DPDK patches and discussions
 help / color / mirror / Atom feed
From: Shahaf Shuler <shahafs@mellanox.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
	Mordechay Haimovsky <motih@mellanox.com>,
	"pascal.mazon@6wind.com" <pascal.mazon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH V5 2/2] net/tap: use new Rx offloads API
Date: Mon, 12 Mar 2018 14:20:48 +0000	[thread overview]
Message-ID: <DB7PR05MB442687A62B4A408ACC1BBCB9C3D30@DB7PR05MB4426.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <95d434f5-438a-19a7-1227-18c1230201c0@intel.com>



--Shahaf


> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, March 2, 2018 11:44 PM
> To: Mordechay Haimovsky <motih@mellanox.com>;
> pascal.mazon@6wind.com
> Cc: dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH V5 2/2] net/tap: use new Rx offloads API
> 
> On 1/17/2018 2:04 PM, Moti Haimovsky wrote:
> > Ethdev Rx offloads API has changed since:
> > commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API") This
> > commit adds support for the new Rx offloads API.
> >
> > Signed-off-by: Moti Haimovsky <motih@mellanox.com>
> 
> <...>
> 
> > +static bool
> > +tap_rxq_are_offloads_valid(struct rte_eth_dev *dev, uint64_t
> > +offloads) {
> > +	uint64_t port_offloads = dev->data->dev_conf.rxmode.offloads;
> > +	uint64_t queue_supp_offloads = tap_rx_offload_get_queue_capa();
> > +	uint64_t port_supp_offloads = tap_rx_offload_get_port_capa();
> > +
> > +	if ((offloads & (queue_supp_offloads | port_supp_offloads)) !=
> > +	    offloads)
> > +		return false;
> > +	if ((port_offloads ^ offloads) & port_supp_offloads)
> > +		return false;
> 
> Hi Moti,
> 
> I am getting following error when tried to use tap with bonding:
> "Rx queue offloads 0x0 don't match port offloads 0x1000 or supported
> offloads 0x300e"
> 
> What is the intention here? I guess it tries to be sure requested queue
> offloads is subsets of port_offloads and offload_capability.
> If so not requesting any queue offload should be valid, isn't it?


 Port offload should be enabled on both port and queue configuration. This is part of the documentation [1], section "8.4.7.1. Per-Port and Per-Queue Offloads"
 On the above case, you try to enable the DEV_RX_OFFLOAD_CRC_STRIP on the port without enabling it on the queues. I guess DEV_RX_OFFLOAD_CRC_STRIP is reported by the tap PMD as port (and not queue) offload.

To answer some question asked privately by Ferruh:
>Why queue offload values should be set to enable per-port offload? I think this is wrong. We don't do queue offload at all, don't use that value, but this suggest that value should be some specific value to work, why?

The logic behind it was to make the offloads enablement more explicit.
Consider port offload is set on device configuration, but not set on the queue. there is an uncertainty whether the application wanted to "not enable" this offload or it was just not set (like in your case).

There other way around also makes sense: if offload was set on the port configuration then it is applied to each of the queues, with no way for the application to disable it through the queue configuration. 

The current API choose option #1, we can discuss to do small change to move to #2. 

>
>I believe other way around makes sense, to be able to set queue offload param, device should announce that offloading as supported. Queue is subset of the device, why you ignore device offload param to set queue offload param?
>
>What makes sense to me:
>"queue offload" is subset of "device offload" is subset of "device supported offload"




[1]
http://dpdk.org/doc/guides/prog_guide/poll_mode_drv.html


> 
> <...>

  reply	other threads:[~2018-03-12 14:20 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-04 19:18 [dpdk-dev] [PATCH V3 0/2] net/tap: convert to new ethdev " Moti Haimovsky
2018-01-04 19:18 ` [dpdk-dev] [PATCH V3 1/2] net/tap: convert to new Tx " Moti Haimovsky
2018-01-05  8:18   ` Pascal Mazon
2018-01-04 19:18 ` [dpdk-dev] [PATCH V3 2/2] net/tap: convert to new Rx " Moti Haimovsky
2018-01-05  8:26   ` Pascal Mazon
2018-01-10 16:20   ` [dpdk-dev] [PATCH V4 1/2] net/tap: convert to new Tx " Moti Haimovsky
2018-01-10 16:20     ` [dpdk-dev] [PATCH V4 2/2] net/tap: convert to new Rx " Moti Haimovsky
2018-01-10 16:42       ` Pascal Mazon
2018-01-17 14:04       ` [dpdk-dev] [PATCH V5 1/2] net/tap: use new Tx " Moti Haimovsky
2018-01-17 14:04         ` [dpdk-dev] [PATCH V5 2/2] net/tap: use new Rx " Moti Haimovsky
2018-03-02 21:44           ` Ferruh Yigit
2018-03-12 14:20             ` Shahaf Shuler [this message]
2018-03-12 16:59               ` Ferruh Yigit
2018-03-12 17:58                 ` Shahaf Shuler
2018-03-12 19:05                   ` Ferruh Yigit
2018-03-13  7:08                     ` Shahaf Shuler
2018-03-13 11:56                       ` Ferruh Yigit
2018-03-14  5:49                         ` Shahaf Shuler
2018-03-14 22:40                           ` Ferruh Yigit
2018-03-15  6:16                             ` Shahaf Shuler
2018-03-15 14:34                               ` Ferruh Yigit
2018-01-18 14:02         ` [dpdk-dev] [PATCH V5 1/2] net/tap: use new Tx " Pascal Mazon
2018-01-18 15:19           ` Ferruh Yigit

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=DB7PR05MB442687A62B4A408ACC1BBCB9C3D30@DB7PR05MB4426.eurprd05.prod.outlook.com \
    --to=shahafs@mellanox.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=motih@mellanox.com \
    --cc=pascal.mazon@6wind.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).