On 4/24/2018 12:08 PM, Ananyev, Konstantin wrote: > Hi Ferruh, > >> >> On 3/30/2018 2:47 PM, Thomas Monjalon wrote: >>> 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? >> >> There is a detail of ability to disabling queue level offloads in >> queue_setup() >> function, I want to discuss here. >> >> Prolog: >> port level offload: An offload only can be applied port level, to all queues. >> queue level offload: An offload can be applied into individual queues of the >> port >> >> PMD reports port offload capability: port level offload + queue level offload >> PMD reports queue offload capability: queue level offload >> >> >> Above suggested change to API: >> - Application will be limited in configure() to set only an offload within >> "port >> offload capability" >> - Application will be limited in queue_setup() to set only an offload within >> "queue offload capability" >> >> >> This doesn't say much about disabling an offload in queue_setup(), as a rule: >> - An "port level offload" can't be disabled in queue_setup() >> >> >> There are two cases of disable: >> 1- Disabling a "queue level offload" enabled queue_setup() previously >> 2- Disabling a "queue level offload" enabled in configure() >> >> If second is not supported, to disable the offload, applications should >> stop->re-configure()->re-queue_setup()->start the port. But having this >> capability makes the offloading parameters more confusing for applications. >> >> >> I suggest adding disable support to fist one but not second one. > > Not sure why to introduce such limitation?
Not supporting second one? To differentiate disable request for that case is harder. How can we say to disable a "queue level offloads" enabled by configure()? It may be by setting these offloads in queue_setup() as well and when any offload is missing in queue_setup() it can be taken as disable request. This forces applications to duplicate/set "queue level offloads" enabled by configure() in the queue_setup() function by default. This is an option, but my concern was to this may be harder to manage by applications. An application will have to remove "port level offload" from port_offloads and feed it into each queue_setup(). Also this is closer to existing API but not same, the difference is queue_setup() doesn't get "port level offload" We can go with this one if there is a requirement for it. And if we prefer to go with this option, perhaps we can think twice about changing exiting API because this will be very close the existing API. Only logically it is not correct to force application to set some offloads in queue_setup() for the PMD that doesn't support queue offload at all, this can be handled in PMD, and saves us of all the trouble of the change. > Konstantin >
