DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Wang, Haiyue" <haiyue.wang@intel.com>
To: Andrew Rybchenko <arybchenko@solarflare.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "Yigit, Ferruh" <ferruh.yigit@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-significant bits for PMD scartch
Date: Fri, 21 Jun 2019 07:37:40 +0000	[thread overview]
Message-ID: <E3B9F2FDCB65864C82CD632F23D8AB87733850E5@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <3500154e-74e5-d4f7-6606-ad1fea300f0e@solarflare.com>

Then this is not so generic if a workaround is needed. In other words, no one is so perfect. ☺

BR,
Haiyue

From: Andrew Rybchenko [mailto:arybchenko@solarflare.com]
Sent: Friday, June 21, 2019 15:34
To: Wang, Haiyue <haiyue.wang@intel.com>; dev@dpdk.org
Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-significant bits for PMD scartch

On 6/21/19 4:12 AM, Wang, Haiyue wrote:
Not so frightening in real world for an application to be aware of its NICs:
https://github.com/Juniper/contrail-vrouter/blob/master/dpdk/vr_dpdk_ethdev.c#L387<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Juniper_contrail-2Dvrouter_blob_master_dpdk_vr-5Fdpdk-5Fethdev.c-23L387&d=DwMGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=flTOx6Av679My7o_iScb5sOlLD68bpUyE2RUtfW3SWQ&m=XSIm84nALkE7O1aeqpJkVJJWzepVsGEJsTeiDCxoLK4&s=L1vEJ5GeVHbammKc0iJn0YdoeKf0GqeeNJy-q5xCi6E&e=>



In this particular case it is just a workaround for bonding and bnxt.
Driver name is provided and sufficient to make it possible when
absolutely required.



Yes, we need to avoid this kind of design.

BR,
Haiyue

From: Andrew Rybchenko [mailto:arybchenko@solarflare.com]
Sent: Friday, June 21, 2019 02:30
To: Wang, Haiyue <haiyue.wang@intel.com><mailto:haiyue.wang@intel.com>; dev@dpdk.org<mailto:dev@dpdk.org>
Cc: Yigit, Ferruh <ferruh.yigit@intel.com><mailto:ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net><mailto:thomas@monjalon.net>
Subject: Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-significant bits for PMD scartch

CC ethdev maintainers

On 6/20/19 10:25 AM, Haiyue Wang wrote:

Generally speaking, the DEV_RX_OFFLOAD_xxx for RX offload capabilities

of a device is one-bit field definition, it has 64 different values at

most.



Nowdays the receiving queue of NIC has rich features not just checksum

offload, like it can extract the network protocol header fields to its

RX descriptors for quickly handling. But this kind of feature is not so

common, and it is hardware related. Normally, this can be done through

rte_devargs driver parameters, but the scope is per device. This is not

so nice for per queue design.



The per queue API 'rte_eth_rx_queue_setup' and data structure 'struct

rte_eth_rxconf' are stable now, and be common for all PMDs. For keeping

the ethdev API & ABI compatibility, and the application can make good

use of the NIC's specific features, reserving the most-significant bits

of RX offload seems an compromise method.



Then the PMDs redefine these bits as they want, all PMDs share the same

bit positions and expose their new definitions with the header file.



The experimental reserved bits number is 6 currently. Tt can be one-bit

for each features up to the the maximum number 6. It can also be some

bits encoding: e.g, 6 bits can stand for 63 maximum number of features.



We call these reserved bits as DEV_RX_OFFLOAD_PMD_SCRATCH. And the left

unused bits number is : 64 - 19 (currently defined) - 6 (PMD scartch) =

39.



This is not so nice for applications, they need to check PMD's driver

name for lookuping their DEV_RX_OFFLOAD_PMD_SCRATCH definitions. But it

is good for the applications to make use of the hardware compatibility.



Signed-off-by: Haiyue Wang <haiyue.wang@intel.com><mailto:haiyue.wang@intel.com>

I would say that it very bad for applications. It sounds like reserved bits
in registers which have meaning in fact and sometimes different meaning.
Of course, it is not that bad when rules are defined, but such kind of
features tend to spread and clutter up interfaces. IMHO, the feature is
really frightening.


  reply	other threads:[~2019-06-21  7:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-20  7:25 Haiyue Wang
2019-06-20 18:30 ` Andrew Rybchenko
2019-06-21  1:12   ` Wang, Haiyue
2019-06-21  7:33     ` Andrew Rybchenko
2019-06-21  7:37       ` Wang, Haiyue [this message]
2019-06-21  7:39         ` Andrew Rybchenko
2019-06-21  7:43           ` Wang, Haiyue
2019-06-21 15:14             ` Stephen Hemminger
2019-06-21 16:37               ` Wang, Haiyue
2019-06-21 16:45                 ` David Marchand
2019-06-21 16:57                   ` Wang, Haiyue
2019-06-20 18:35 ` Stephen Hemminger
2019-06-21  0:55   ` Wang, Haiyue

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=E3B9F2FDCB65864C82CD632F23D8AB87733850E5@SHSMSX101.ccr.corp.intel.com \
    --to=haiyue.wang@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=thomas@monjalon.net \
    /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).