[dpdk-dev] Survey for final decision about per-port offload API

Patil, Harish Harish.Patil at cavium.com
Mon Apr 2 19:39:56 CEST 2018


-----Original Message-----
From: Thomas Monjalon <thomas at monjalon.net>
Date: Friday, March 30, 2018 at 6:47 AM
To: "dev at dpdk.org" <dev at dpdk.org>
Cc: Ajit Khaparde <ajit.khaparde at broadcom.com>, "Jacob,  Jerin"
<Jerin.JacobKollanukkaran at cavium.com>, "Thotton, Shijith"
<Shijith.Thotton at cavium.com>, "Shukla, Santosh"
<Santosh.Shukla at cavium.com>, Rahul Lakkireddy
<rahul.lakkireddy at chelsio.com>, John Daley <johndale at cisco.com>, Wenzhuo
Lu <wenzhuo.lu at intel.com>, Konstantin Ananyev
<konstantin.ananyev at intel.com>, Beilei Xing <beilei.xing at intel.com>, Qi
Zhang <qi.z.zhang at intel.com>, Jingjing Wu <jingjing.wu at intel.com>, Adrien
Mazarguil <adrien.mazarguil at 6wind.com>, Nelio Laranjeiro
<nelio.laranjeiro at 6wind.com>, Yongseok Koh <yskoh at mellanox.com>, Shahaf
Shuler <shahafs at mellanox.com>, Tomasz Duszynski <tdu at semihalf.com>, Jianbo
Liu <jianbo.liu at arm.com>, Alejandro Lucero
<alejandro.lucero at netronome.com>, Hemant Agrawal <hemant.agrawal at nxp.com>,
Shreyansh Jain <shreyansh.jain at nxp.com>, Harish Patil
<Harish.Patil at cavium.com>, "Mody, Rasesh" <Rasesh.Mody at cavium.com>, Andrew
Rybchenko <arybchenko at solarflare.com>, Shrikrishna Khare
<skhare at vmware.com>, Maxime Coquelin <maxime.coquelin at redhat.com>, Allain
Legacy <allain.legacy at windriver.com>, Bruce Richardson
<bruce.richardson at intel.com>, Gaetan Rivet <gaetan.rivet at 6wind.com>,
Olivier Matz <olivier.matz at 6wind.com>
Subject: Survey for final decision about per-port offload API

>There are some discussions about a specific part of the offload API:
>	"To enable per-port offload, the offload should be set on both
>	device configuration and queue setup."
>
>It means the application must repeat the port offload flags
>in rte_eth_conf.[rt]xmode.offloads and rte_eth_[rt]xconf.offloads,
>when calling respectively rte_eth_dev_configure() and
>rte_eth_[rt]x_queue_setup for each queue.
>
>The PMD must check if there is mismatch, i.e. a port offload not
>repeated in queue setup.
>There is a proposal to do this check at ethdev level:
>	http://dpdk.org/ml/archives/dev/2018-March/094023.html
>
>It was also proposed to relax the API and allow "forgetting" port
>offloads in queue offloads:
>	http://dpdk.org/ml/archives/dev/2018-March/092978.html
>
>It would mean the offloads applied to a queue result of OR operation:
>	rte_eth_conf.[rt]xmode.offloads | rte_eth_[rt]xconf.offloads
>
>1/ Do you agree with above API change?

Yes. But pls confirm that this would still work properly if RX supports
port-only based offloads and doesn’t support queue based offloads at all,
as advertised in dev_infos_get().

dev_info->rx_queue_offload_capa = 0 and
dev_info->rx_offload_capa = (DEV_RX_OFFLOAD_IPV4_CKSUM | ...);


>
>
>If we agree with this change, we need to update the documentation
>and remove the checks in PMDs.
>Note: no matter what is decided here, 18.05-rc1 should have all PMDs
>switched to the API which was defined in 17.11.
>Given that API is new and not yet adopted by the applications,
>the sonner it is fixed, the better.
>
>2/ Should we do this change in 18.05-rc2?
>
Yes
>
>At the same time, we want to make clear that an offload enabled at
>port level, cannot be disabled at queue level.
>
>3/ Do you agree with above statement (to be added in the doc)?
Yes
>
>
>There is the same kind of confusion in the offload capabilities:
>	rte_eth_dev_info.[rt]x_offload_capa
>	rte_eth_dev_info.[rt]x_queue_offload_capa
>The queue capabilities must be a subset of port capabilities,
>i.e. every queue capabilities must be reported as port capabilities.
>But the port capabilities should be reported at queue level
>only if it can be applied to a specific queue.
>
>4/ Do you agree with above statement (to be added in the doc)?

Yes
>
>
>Please give your opinion on questions 1, 2, 3 and 4.
>Answering by yes/no may be sufficient in most cases :)
>Thank you
>
>



More information about the dev mailing list