patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Lance Richardson <lance.richardson@broadcom.com>
Cc: Wenzhuo Lu <wenzhuo.lu@intel.com>,
	Xiaoyun Li <xiaoyun.li@intel.com>,
	Bernard Iremonger <bernard.iremonger@intel.com>,
	Steve Yang <stevex.yang@intel.com>,
	dev@dpdk.org, stable@dpdk.org, oulijun@huawei.com,
	wisamm@mellanox.com, lihuisong@huawei.com
Subject: Re: [dpdk-stable] [PATCH v5] app/testpmd: fix setting maximum packet length
Date: Tue, 26 Jan 2021 11:01:09 +0000	[thread overview]
Message-ID: <21284291-2b31-3518-5883-33237dd30bea@intel.com> (raw)
In-Reply-To: <CADyeNEBUB3wth=TS7+X12+_WZf+eR-bVH1GROrtCuKWx6gyXEQ@mail.gmail.com>

On 1/26/2021 3:45 AM, Lance Richardson wrote:
> On Mon, Jan 25, 2021 at 7:44 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>>
>>>> +       if (rx_offloads != port->dev_conf.rxmode.offloads) {
>>>> +               uint16_t qid;
>>>> +
>>>> +               port->dev_conf.rxmode.offloads = rx_offloads;
>>>> +
>>>> +               /* Apply JUMBO_FRAME offload configuration to Rx queue(s) */
>>>> +               for (qid = 0; qid < port->dev_info.nb_rx_queues; qid++) {
>>>> +                       if (on)
>>>> +                               port->rx_conf[qid].offloads |= DEV_RX_OFFLOAD_JUMBO_FRAME;
>>>> +                       else
>>>> +                               port->rx_conf[qid].offloads &= ~DEV_RX_OFFLOAD_JUMBO_FRAME;
>>>> +               }
>>>
>>> Is it correct to set per-queue offloads that aren't advertised by the PMD
>>> as supported in rx_queue_offload_capa?
>>>
>>
>> 'port->rx_conf[]' is testpmd struct, and 'port->dev_conf.rxmode.offloads' values
>> are reflected to 'port->rx_conf[].offloads' for all queues.
>>
>> We should set the offload in 'port->rx_conf[].offloads' if it is set in
>> 'port->dev_conf.rxmode.offloads'.
>>
>> If a port has capability for 'JUMBO_FRAME', 'port->rx_conf[].offloads' can have
>> it. And the port level capability is already checked above.
>>
> 
> I'm still not 100% clear about the per-queue offload question.
> 
> With this patch, and jumbo max packet size configured (on the command
> line in this case), I see:
> 
> testpmd> show port 0 rx_offload configuration
> Rx Offloading Configuration of port 0 :
>    Port : JUMBO_FRAME
>    Queue[ 0] : JUMBO_FRAME
> 
> testpmd> show port 0 rx_offload capabilities
> Rx Offloading Capabilities of port 0 :
>    Per Queue :
>    Per Port  : VLAN_STRIP IPV4_CKSUM UDP_CKSUM TCP_CKSUM TCP_LRO
> OUTER_IPV4_CKSUM VLAN_FILTER VLAN_EXTEND JUMBO_FRAME SCATTER TIMESTAMP
> KEEP_CRC OUTER_UDP_CKSUM RSS_HASH
> 

The port level offload is applied to all queues on the port, testpmd config 
structure reflects this logic in implementation.
If Rx offload X is set for a port, it is set for all Rx queue offloads, this is 
not new behavior and not related to this patch.

In the ethdev, lets assume X & Y are port level offloads,
after X, Y are set via 'rte_eth_dev_configure()'
if user calls 'rte_eth_rx_queue_setup()' with X & Y offload, this is a valid 
call and API will return success, since those offloads already enabled in port 
level means they are enabled for all queues.

Because of above ethdev behavior, testpmd keeps all enabled port level offload 
in the queue level offload too, and display them as enabled offloads for the queue.

To request a queue specific offload, it is added to specific queue's config 
before calling queue setup. Lets say that queue specific offload is Z, after 
setup testpmd config struct will show that specific queue has X, Y & Z offloads.

I hope it is more clear now.

> Yet if I configure a jumbo MTU starting with standard max packet size,
> jumbo is only enabled at the port level:
> testpmd> port config mtu 0 9000
> testpmd> port start all
> 
> testpmd> show port 0 rx_offload configuration
> Rx Offloading Configuration of port 0 :
>    Port : JUMBO_FRAME
>    Queue[ 0] :
> 
> It still seems odd for a per-queue offload to be enabled on a PMD that
> doesn't support per-queue receive offloads.
> 

"port config mtu" should take queue offloads into account, it looks wrong right now.



  parent reply	other threads:[~2021-01-26 11:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210125083202.38267-1-stevex.yang@intel.com>
2021-01-25 18:15 ` Ferruh Yigit
2021-01-25 19:41   ` Lance Richardson
2021-01-26  0:44     ` Ferruh Yigit
2021-01-26  3:22       ` Lance Richardson
2021-01-26  3:45       ` Lance Richardson
2021-01-26  7:54         ` Li, Xiaoyun
2021-01-26 11:01         ` Ferruh Yigit [this message]
2021-01-28 21:36           ` Lance Richardson
2021-01-28 22:12             ` Ferruh Yigit
2021-01-26  9:02   ` Wisam Monther
2021-01-27  3:04   ` Li, Xiaoyun
2021-01-28  1:57     ` Chen, BoX C
2021-01-28  9:18   ` Wisam Monther
2021-01-28  9:26     ` Ferruh Yigit
2021-01-28 11:08       ` Wisam Monther
2021-01-28 12:07   ` [dpdk-stable] [PATCH v6] " Ferruh Yigit
2021-01-29  9:34     ` 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=21284291-2b31-3518-5883-33237dd30bea@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=bernard.iremonger@intel.com \
    --cc=dev@dpdk.org \
    --cc=lance.richardson@broadcom.com \
    --cc=lihuisong@huawei.com \
    --cc=oulijun@huawei.com \
    --cc=stable@dpdk.org \
    --cc=stevex.yang@intel.com \
    --cc=wenzhuo.lu@intel.com \
    --cc=wisamm@mellanox.com \
    --cc=xiaoyun.li@intel.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).