Wednesday, March 21, 2018 1:09 PM, Andrew Rybchenko
> On 03/21/2018 01:54 PM, Ferruh Yigit wrote:
> > On 3/21/2018 9:47 AM, Andrew Rybchenko wrote:
> >> On 03/16/2018 06:51 PM, Ferruh Yigit wrote:
> >>> Don't mandate API to pass port offload configuration during queue
> >>> setup, this is unnecessary for devices that support only port level
> offloads.
> >>>
> >>> Fixes: 81ac560dc1b4 ("doc: add details on ethdev offloads API")
> >>> Cc: shah...@mellanox.com
> >>>
> >>> Signed-off-by: Ferruh Yigit <ferruh.yi...@intel.com>
> >>> ---
> >>> Cc: Patil, Harish <harish.pa...@cavium.com>
> >>>
> >>> Btw, this expectation from API should be clear from source code and
> >>> API documentation (doxygen comments in header file) instead of
> >>> documentation. Am I missing something or we are doing something
> >>> wrong here?
> >>> ---
> >>> doc/guides/prog_guide/poll_mode_drv.rst | 4 +---
> >>> 1 file changed, 1 insertion(+), 3 deletions(-)
> >>>
> >>> diff --git a/doc/guides/prog_guide/poll_mode_drv.rst
> >>> b/doc/guides/prog_guide/poll_mode_drv.rst
> >>> index e5d01874e..3247f309f 100644
> >>> --- a/doc/guides/prog_guide/poll_mode_drv.rst
> >>> +++ b/doc/guides/prog_guide/poll_mode_drv.rst
> >>> @@ -303,9 +303,7 @@ Supported offloads can be either per-port or per-
> queue.
> >>> Offloads are enabled using the existing ``DEV_TX_OFFLOAD_*`` or
> ``DEV_RX_OFFLOAD_*`` flags.
> >>> Per-port offload configuration is set using ``rte_eth_dev_configure``.
> >>> Per-queue offload configuration is set using
> ``rte_eth_rx_queue_setup`` and ``rte_eth_tx_queue_setup``.
> >>> -To enable per-port offload, the offload should be set on both device
> configuration and queue setup.
> >>> -In case of a mixed configuration the queue setup shall return with an
> error.
> >>> -To enable per-queue offload, the offload can be set only on the queue
> setup.
> >>> +Per-port offloads should be set on the port configuration. Queue
> offloads should be set on the queue configuration.
> >>> Offloads which are not enabled are disabled by default.
> >>>
> >>> For an application to use the Tx offloads API it should set the
> ``ETH_TXQ_FLAGS_IGNORE`` flag in the ``txq_flags`` field located in
> ``rte_eth_txconf`` struct.
> >> net/sfc has code which double-checks old behaviour. So, it is not
> >> just documentation update. We can provide patches if the behaviour
> >> change is accepted.
> > Not definitely just doc update, PMDs needs to be modified. This patch
> > is just to agree on the behavior.
> >
> >> IMHO, it should be allowed to specify queue offloads on port level.
> >> It should simply enable these offloads on all queues. Also it will
> >> match dev_info [rt]x_offload_capa which include both port and queue
> >> offloads.
> >>
> >> Yes, we lose possibility to enable on port level, but disable on
> >> queue level by suggested changes, but I think it is OK - if you don't
> >> need it for all queues, just control separately on queue level.
> > What I understand was queue offload can only enable more, but it seems
> > it can both enable or disable.
> >
> > My concern was, even PMD reports no [rt]x_offload_capa at all, API
> > forces application to send at least port offloads during queue setup.
>
> I guess you mean [rt]x_queue_offload_capa above.
>
> > As long as application only allowed to send queue offloads within the
> > boundaries of the "queue offload capabilities", I am OK.
>
> If so, queue offloads should not be included in [rt]x_offload_capa.
> But I'm afraid it is too restrictive for apps.
>
> > This will work fine for devices that support queue level offloads to
> > enable - disable queue specific offloads on top of port offloads. Will this
> make sense?
>
> IMHO, disable on queue level is not required for enabled on port level.
> If app always wants some offloads, just check [rt]x_offload_capa and enable
> on port level (regardless if it is actually per-port or per-queue).
> If app wants to some offload per queue, check [rt]x_queue_offload_capa,
> do not enable on port level and control on queue level.
+1.
And I think Ferruh this is the suggestion by this patch, isn't it?
