From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Dai, Wei" <wei.dai@intel.com>,
"Zhang, Qi Z" <qi.z.zhang@intel.com>,
"Wang, Xiao W" <xiao.w.wang@intel.com>
Cc: "'dev@dpdk.org'" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API
Date: Tue, 3 Apr 2018 10:48:05 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB977258A0AB7CE6@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <49759EB36A64CF4892C1AFEC9231E8D66CF66147@PGSMSX112.gar.corp.intel.com>
> -----Original Message-----
> From: Dai, Wei
> Sent: Tuesday, April 3, 2018 8:11 AM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Wang, Xiao W <xiao.w.wang@intel.com>
> Cc: 'dev@dpdk.org' <dev@dpdk.org>
> Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API
>
> Thanks, Konstantin and Zhang Qi for your feedback and support.
> I have talked with Qi and know following:
> To avoid packet dropping when FM10K_SRRCTL_BUFFER_CHAINING_EN is not set,
> the queue can work with a different mempool which has larger mem buffer size.
> For example, SCATTER is enabled on queue 0 with a small mem buffer size of mempool 0,
> And SCATTER is disabled on queue 1 with a large mem buffer size of mempool 1,
> Both queues can avoid packet dropping.
> Indeed, current fm10k PMD also automatically set FM10K_SRRCTL_BUFFER_CHAINING_EN
> If max_rx_pkt_len + 2 * VLAN_TAG_SIZE > mem_buf_size no matter whether SCATTER is enabled
> on queue configuration or not.
You can make it just MULTISEG a port offload (not queue) and
in that case none of the queues will drop the packets.
But again - up to you guys, both approaches are possible, I think.
Konstantin
>
>
> > -----Original Message-----
> > From: Ananyev, Konstantin
> > Sent: Sunday, April 1, 2018 8:09 PM
> > To: Zhang, Qi Z <qi.z.zhang@intel.com>; Dai, Wei <wei.dai@intel.com>;
> > Wang, Xiao W <xiao.w.wang@intel.com>
> > Cc: 'dev@dpdk.org' <dev@dpdk.org>
> > Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx
> > offloads API
> >
> > Hi Qi,
> >
> > > > > > > >
> > > > > > > > Hi Daiwei:
> > > > > > > >
> > > > > > > > > +static uint64_t fm10k_get_rx_queue_offloads_capa(struct
> > > > > > > > > +rte_eth_dev
> > > > > > > > > +*dev) {
> > > > > > > > > + RTE_SET_USED(dev);
> > > > > > > > > +
> > > > > > > > > + return (uint64_t)(DEV_RX_OFFLOAD_SCATTER);
> > > > > > > > > +}
> > > > > > > >
> > > > > > > > why per queue rx scattered feature here?
> > > > > > > > My understanding is either we use scattered rx function that
> > > > > > > > enable this feature for all queues or we use non-scattered
> > > > > > > > rx function that disable this feature for all queues, right?
> > > > > > >
> > > > > > > Checked with Dai Wei offline, fm10k have per queue register
> > > > > > > that can be configured to support rx scattered, So it is per queue
> > offload.
> > > > > >
> > > > > > Ok, but these days we have one RX function per device.
> > > > > > Looking at fm10k - it clearly has different RX function for
> > > > > > scattered and non-scattered case.
> > > > > > Yes, HW does support scatter/non-scatter selection per queue,
> > > > > > but our SW - doesn't (same for ixgbe and i40e) So how it could
> > > > > > be per queue
> > > > offload?
> > > > >
> > > > > We saw the implementation of fm10k is a little bit different with i40e.
> > > > > It set per queue register "FM10K_SRRCTL_BUFFER_CHAINING_EN" to
> > > > > turn
> > > > on multi-seg feature when offload is required.
> > > > >
> > > > > That means two queues can have different behavior when process a
> > > > > packet that exceed the buffer size base on the register setting,
> > > > > though we
> > > > use the same rx scattered function, so we think this is per queue
> > > > feature, is that make sense?
> > > >
> > > > Ok, suppose we have 2 functions configured.
> > > > One with DEV_RX_OFFLOAD_SCATTER is on, second with
> > > > DEV_RX_OFFLOAD_SCATTER is off.
> > > > So scatter RX function will be selected, but for second queue HW
> > > > support will not be enabled, so packets bigger then RX buffer will
> > > > be silently dropped by HW, right?
> > >
> > > Yes according to datasheet
> > >
> > > Bit FM10K_SRRCTL_BUFFER_CHAINING_EN:
> > >
> > > 0b = Any packet longer than the data buffer size is terminated with a
> > > TOO_BIG error status in Rx descriptor write-back. The remainder of the
> > > frame is not posted to host, it is silently dropped.
> > > 1b = A packet can be spread over more than one single receive data
> > > buffer
> > >
> >
> > Ok, that's a bit unusual approach but understandable.
> > Thanks
> > Konstantin
next prev parent reply other threads:[~2018-04-03 10:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-02 14:11 [dpdk-dev] [PATCH] net/fm10k: convert to new Rx/Tx " Wei Dai
2018-03-19 3:54 ` Zhang, Qi Z
2018-03-28 2:56 ` Dai, Wei
2018-03-28 8:00 ` [dpdk-dev] [PATCH v2 0/2] " Wei Dai
2018-03-28 8:00 ` [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx " Wei Dai
2018-03-28 10:07 ` Zhang, Qi Z
2018-03-29 6:08 ` Zhang, Qi Z
2018-03-29 9:29 ` Ananyev, Konstantin
2018-03-29 9:51 ` Zhang, Qi Z
2018-03-29 10:21 ` Ananyev, Konstantin
2018-03-29 10:29 ` Zhang, Qi Z
2018-04-01 12:08 ` Ananyev, Konstantin
2018-04-03 7:10 ` Dai, Wei
2018-04-03 10:48 ` Ananyev, Konstantin [this message]
2018-04-04 16:26 ` Ferruh Yigit
2018-03-28 8:00 ` [dpdk-dev] [PATCH v2 2/2] net/fm10k: convert to new Tx " Wei Dai
2018-03-29 6:22 ` [dpdk-dev] [PATCH v2 0/2] net/fm10k: convert to new Rx/Tx " Zhang, Qi Z
2018-03-29 6:57 ` Zhang, Helin
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=2601191342CEEE43887BDE71AB977258A0AB7CE6@irsmsx105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=dev@dpdk.org \
--cc=qi.z.zhang@intel.com \
--cc=wei.dai@intel.com \
--cc=xiao.w.wang@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).