RE: [RFC v3] eal: add bitset type
> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se] > Sent: Wednesday, 31 January 2024 19.46 > > On 2024-01-31 17:06, Stephen Hemminger wrote: > > On Wed, 31 Jan 2024 14:13:01 +0100 > > Mattias Rönnblom wrote: [...] > > FYI - the linux kernel has a similar but more complete set of > operations. > > It might be more efficient to use unsigned long rather than requiring > > the elements to be uint64_t. Thinking of the few 32 bit platforms. > > > > Keeping it 64-bit avoids a popcount-related #ifdef. DPDK doesn't have > an > equivalent to __builtin_popcountl(). > > How much do we need to care about 32-bit ISA performance? At the 2023 DPDK Summit I talked to someone at a very well known network equipment vendor using 32 bit CPUs in some of their products; some sort of CPE, IIRC. 32 bit CPUs are still out there, and 32-bit CPU support has not been deprecated in DPDK. For the bitset parameter to functions, you could either use "unsigned long*" (as suggested by Stephen), or "void*" (followed by type casting inside the functions). If only using this library for the command line argument parser and similar, performance is irrelevant. If we foresee using it in the fast path, e.g. with the htimer library, we shouldn't tie its API tightly to 64 bit. > > I'll go through the below API and some other APIs to see if there's > something obvious missing. > > When I originally wrote this code there were a few potential features > where I wasn't sure to what extent they were useful. One example was > the > shift operation. Any input is appreciated. Start off with what you already have. If we need more operations, they can always be added later. > > > Also, what if any thread safety guarantees? or atomic. > > > > Currently, it's all MT unsafe. > > An atomic set and get/test would make sense, and maybe other operations > would as well. > > Bringing in atomicity into the design makes it much less obvious: > > Would the atomic operations imply some memory ordering, or be > "relaxed". > I would lean toward relaxed, but then shouldn't bit-level atomics be > consistent with the core DPDK atomics API? With that in mind, memory > ordering should be user-configurable. > > If the code needs to be pure C11 atomics-wise, the words that makes up > the bitset must be _Atomic uint64_t. Then you need to be careful or end > up with "lock"-prefixed instructions if you manipulate the bitset > words. > Just a pure words[N] = 0; gives you a mov+mfence on x86, for example, > plus all the fun memory_order_seq_cst in terms of preventing > compiler-level optimizations. So you definitely can't have the bitset > always using _Atomic uint64_t, since would risk non-shared use cases. > You could have a variant I guess. Just duplicate the whole thing, or > something with macros. It seems like MT unsafe suffices for the near term use cases. We can add an atomic variant of the library later, if the need should arise. > > With GCC C11 builtins, you can both have the atomic cake and eat it, in > that you both access the data non-atomically/normally, and in an atomic > manner. Yep. And we care quite a lot about performance, so we are likely to keep using those until the compilers offer similar performance for C11 standard atomics.
RE: [EXT] [PATCH 1/3] cryptodev: add ec points to sm2 op
> -- > In the case when PMD cannot support full process of the SM2, > but elliptic curve computation only, additional fields > are needed to handle such a case. > Asym crypto APIs are no longer experimental. Hence adding new fields would lead to ABI break. > Points C1, kP therefore were added to the SM2 crypto operation struct. > > Signed-off-by: Arkadiusz Kusztal
Re: [PATCH v2 2/2] vhost: add new mbuf allocation failure statistic
On Wed, Jan 31, 2024 at 8:53 PM Maxime Coquelin
wrote:
>
> This patch introduces a new, per virtqueue, mbuf allocation
> failure statistic. It can be useful to troubleshoot packets
> drops due to insufficient mempool size or memory leaks.
>
> Signed-off-by: Maxime Coquelin
Having a stat for such situation will be useful.
I just have one comment, though it is not really related to this change itself.
[snip]
> diff --git a/lib/vhost/virtio_net.c b/lib/vhost/virtio_net.c
> index 9951842b9f..1359c5fb1f 100644
> --- a/lib/vhost/virtio_net.c
> +++ b/lib/vhost/virtio_net.c
> @@ -2996,6 +2996,7 @@ desc_to_mbuf(struct virtio_net *dev, struct
> vhost_virtqueue *vq,
> if (mbuf_avail == 0) {
> cur = rte_pktmbuf_alloc(mbuf_pool);
> if (unlikely(cur == NULL)) {
> + vq->stats.mbuf_alloc_failed++;
> VHOST_DATA_LOG(dev->ifname, ERR,
> "failed to allocate memory for
> mbuf.");
This error log here is scary as it means the datapath can be slowed
down for each multisegment mbuf in the event of a mbuf (maybe
temporary) shortage.
Besides no other mbuf allocation in the vhost library datapath
generates such log.
I would remove it, probably in a separate patch.
WDYT?
> goto error;
--
David Marchand
Re: [PATCH v2 2/2] vhost: add new mbuf allocation failure statistic
On 2/1/24 09:10, David Marchand wrote:
On Wed, Jan 31, 2024 at 8:53 PM Maxime Coquelin
wrote:
This patch introduces a new, per virtqueue, mbuf allocation
failure statistic. It can be useful to troubleshoot packets
drops due to insufficient mempool size or memory leaks.
Signed-off-by: Maxime Coquelin
Having a stat for such situation will be useful.
I just have one comment, though it is not really related to this change itself.
[snip]
diff --git a/lib/vhost/virtio_net.c b/lib/vhost/virtio_net.c
index 9951842b9f..1359c5fb1f 100644
--- a/lib/vhost/virtio_net.c
+++ b/lib/vhost/virtio_net.c
@@ -2996,6 +2996,7 @@ desc_to_mbuf(struct virtio_net *dev, struct
vhost_virtqueue *vq,
if (mbuf_avail == 0) {
cur = rte_pktmbuf_alloc(mbuf_pool);
if (unlikely(cur == NULL)) {
+ vq->stats.mbuf_alloc_failed++;
VHOST_DATA_LOG(dev->ifname, ERR,
"failed to allocate memory for mbuf.");
This error log here is scary as it means the datapath can be slowed
down for each multisegment mbuf in the event of a mbuf (maybe
temporary) shortage.
Besides no other mbuf allocation in the vhost library datapath
generates such log.
I would remove it, probably in a separate patch.
WDYT?
Agree, we should not have such log in the datapath.
And now that we have the stat, it is even less useful.
Regards,
Maxime
goto error;
RE: [PATCH v2 1/2] ethdev: introduce NAT64 action
Hi Bing > -Original Message- > From: Bing Zhao > Sent: Wednesday, January 31, 2024 11:38 AM > > In order to support the communication between IPv4 and IPv6 nodes in > the network, different technologies are used, like dual-stacks, > tunneling and NAT64. In some IPv4-only clients, it is hard to deploy > new software and(or) hardware to support IPv6 protocol. > > NAT64 is a choice and it will also reduce the unnecessary overhead of > the traffic in the network. The NAT64 gateways take the > responsibility of the packet headers translation between the IPv6 > clouds and IPv4-only clouds. > > The commit introduce the NAT64 flow action to offload the software > involvement to the hardware. > > This action should support the offloading of the IP headers' > translation. The following fields should be reset correctly in the > translation. > - Version > - Traffic Class / TOS > - Flow Label (0 in v4) > - Payload Length / Total length > - Next Header > - Hop Limit / TTL > > The PMD needs to support the basic conversion of the fields above, > and the well-known prefix will be used when translating IPv4 address > to IPv6 address. Another modify fields can be used after the NAT64 to > support other modes with different prefix and offset. > > The ICMP* and transport layers protocol is out of the scope of NAT64 > rte_flow action. > > Reference links: > - https://datatracker.ietf.org/doc/html/rfc6146 > - https://datatracker.ietf.org/doc/html/rfc6052 > - https://datatracker.ietf.org/doc/html/rfc6145 > > Signed-off-by: Bing Zhao > --- Acked-by: Ori Kam Best, Ori
RE: [PATCH v2 2/2] app/testpmd: add support for NAT64 in the command line
> -Original Message-
> From: Bing Zhao
> Sent: Wednesday, January 31, 2024 11:38 AM
>
> The type of NAT64 action will be parsed.
>
> Usage example with template API:
> ...
> flow actions_template 0 create ingress actions_template_id 1 \
> template count / nat64 / jump / end mask count / nat64 / \
> jump / end
> flow template_table 0 create group 1 priority 0 ingress table_id \
> 0x1 rules_number 8 pattern_template 0 actions_template 1
> flow queue 0 create 2 template_table 0x1 pattern_template 0 \
> actions_template 0 postpone no pattern eth / end actions count / \
> nat64 type 1 / jump group 2 / end
>...
>
> Signed-off-by: Bing Zhao
> ---
> app/test-pmd/cmdline_flow.c | 23 +
> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4
> 2 files changed, 27 insertions(+)
>
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index 4062879552..d26986a9ab 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -733,6 +733,8 @@ enum index {
> ACTION_IPV6_EXT_PUSH,
> ACTION_IPV6_EXT_PUSH_INDEX,
> ACTION_IPV6_EXT_PUSH_INDEX_VALUE,
> + ACTION_NAT64,
> + ACTION_NAT64_MODE,
> };
>
> /** Maximum size for pattern in struct rte_flow_item_raw. */
> @@ -2209,6 +2211,7 @@ static const enum index next_action[] = {
> ACTION_QUOTA_QU,
> ACTION_IPV6_EXT_REMOVE,
> ACTION_IPV6_EXT_PUSH,
> + ACTION_NAT64,
> ZERO,
> };
>
> @@ -2550,6 +2553,12 @@ static const enum index
> action_represented_port[] = {
> ZERO,
> };
>
> +static const enum index action_nat64[] = {
> + ACTION_NAT64_MODE,
> + ACTION_NEXT,
> + ZERO,
> +};
> +
> static int parse_set_raw_encap_decap(struct context *, const struct token *,
>const char *, unsigned int,
>void *, unsigned int);
> @@ -7077,6 +7086,20 @@ static const struct token token_list[] = {
> .call = parse_vc_action_ipv6_ext_push_index,
> .comp = comp_set_ipv6_ext_index,
> },
> + [ACTION_NAT64] = {
> + .name = "nat64",
> + .help = "NAT64 IP headers translation",
> + .priv = PRIV_ACTION(NAT64, sizeof(struct
> rte_flow_action_nat64)),
> + .next = NEXT(action_nat64),
> + .call = parse_vc,
> + },
> + [ACTION_NAT64_MODE] = {
> + .name = "type",
> + .help = "NAT64 translation type",
> + .next = NEXT(action_nat64,
> NEXT_ENTRY(COMMON_UNSIGNED)),
> + .args = ARGS(ARGS_ENTRY(struct rte_flow_action_nat64,
> type)),
> + .call = parse_vc_conf,
> + },
> /* Top level command. */
> [SET] = {
> .name = "set",
> diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> index 38ab421547..d1801c1b26 100644
> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> @@ -4169,6 +4169,10 @@ This section lists supported actions and their
> attributes, if any.
>- ``src_ptr``: pointer to source immediate value.
>- ``width``: number of bits to copy.
>
> +- ``nat64``: NAT64 IP headers translation
> +
> + - ``type {unsigned}``: NAT64 translation type
> +
> Destroying flow rules
> ~
>
> --
> 2.34.1
Acked-by: Ori Kam
Best,
Ori
RE: [PATCH 1/4] ethdev: introduce encap hash calculation
Hi Ferruh,
Can you please review my patch?
Thanks,
Ori
> -Original Message-
> From: Ori Kam
> Sent: Sunday, January 28, 2024 11:40 AM
> To: Dariusz Sosnowski ; ferruh.yi...@amd.com;
>
> During the encapsulation of a packet, it is expected to calculate the
> hash value which is based on the original packet (the outer values,
> which will become the inner values).
>
> The tunnel protocol defines which tunnel field should hold this hash,
> but it doesn't define the hash calculation algorithm.
>
> An application that uses flow offloads gets the first few packets
> and then decides to offload the flow. As a result, there are two
> different paths that a packet from a given flow may take.
> SW for the first few packets or HW for the rest.
> When the packet goes through the SW, the SW encapsulates the packet
> and must use the same hash calculation as the HW will do for
> the rest of the packets in this flow.
>
> This patch gives the SW a way to query the hash value
> for a given packet as if the packet was passed through the HW.
>
> Signed-off-by: Ori Kam
> ---
> doc/guides/prog_guide/rte_flow.rst | 22
> doc/guides/rel_notes/release_24_03.rst | 4 +++
> lib/ethdev/rte_flow.c | 25 +
> lib/ethdev/rte_flow.h | 50 ++
> lib/ethdev/rte_flow_driver.h | 5 +++
> lib/ethdev/version.map | 1 +
> 6 files changed, 107 insertions(+)
>
> diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> index 900fdaefb6..0435dda3c7 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -4211,6 +4211,28 @@ as it would be calculated in the HW.
> uint8_t pattern_template_index,
> uint32_t *hash, struct rte_flow_error
> *error);
>
> +Calculate encap hash
> +
> +
> +Calculating hash of a packet in SW as it would be calculated in HW for the
> encap action
> +
> +When the HW execute an encapsulation action, it may calculate an hash
> value which is based
> +on the original packet. This hash is stored depending on the encapsulation
> protocol, in one
> +of the outer fields.
> +
> +This function allows the application to calculate the hash for a given packet
> as if the
> +encapsulation was done in HW.
> +
> +.. code-block:: c
> +
> + int
> + rte_flow_calc_encap_hash(uint16_t port_id,
> +const struct rte_flow_item pattern[],
> +enum rte_flow_encap_hash_field
> dest_field,
> +uint8_t hash_len,
> +uint8_t *hash,
> +struct rte_flow_error *error);
> +
> .. _flow_isolated_mode:
>
> Flow isolated mode
> diff --git a/doc/guides/rel_notes/release_24_03.rst
> b/doc/guides/rel_notes/release_24_03.rst
> index 5e545da867..80af380172 100644
> --- a/doc/guides/rel_notes/release_24_03.rst
> +++ b/doc/guides/rel_notes/release_24_03.rst
> @@ -75,6 +75,10 @@ New Features
>* Added support for VXLAN-GPE matching in HW Steering flow engine
> (``dv_flow_en`` = 2).
>
> +* **Added ability to calculate the encap hash as done by HW.**
> +
> + * Added function that calculates the encap hash, as the HW calculates it:
> +``rte_flow_calc_encap_hash()``
>
> Removed Items
> -
> diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
> index 3f58d792f9..7fce754be1 100644
> --- a/lib/ethdev/rte_flow.c
> +++ b/lib/ethdev/rte_flow.c
> @@ -2482,3 +2482,28 @@ rte_flow_calc_table_hash(uint16_t port_id, const
> struct rte_flow_template_table
> hash, error);
> return flow_err(port_id, ret, error);
> }
> +
> +int
> +rte_flow_calc_encap_hash(uint16_t port_id, const struct rte_flow_item
> pattern[],
> + enum rte_flow_encap_hash_field dest_field, uint8_t
> hash_len,
> + uint8_t *hash, struct rte_flow_error *error)
> +{
> + int ret;
> + struct rte_eth_dev *dev;
> + const struct rte_flow_ops *ops;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + ops = rte_flow_ops_get(port_id, error);
> + if (!ops || !ops->flow_calc_encap_hash)
> + return rte_flow_error_set(error, ENOTSUP,
> +
> RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
> + "calc encap hash is not supported");
> + if ((dest_field == RTE_FLOW_ENCAP_HASH_FIELD_SRC_PORT &&
> hash_len != 2) ||
> + (dest_field == RTE_FLOW_ENCAP_HASH_FIELD_NVGRE_FLOW_ID
> && hash_len != 1))
> + return rte_flow_error_set(error, EINVAL,
> +
> RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
> + "hash len doesn't match the
> requested field len");
> + dev = &rte_eth_devices[port_id];
> + ret = ops->flow_calc_encap_hash(dev, pattern, dest_f
[PATCH] ethdev: recommend against using locks in event callbacks
As described in a recent bugzilla opened against the net/iavf driver,
a driver may call a event callback from other calls of the ethdev API.
Nothing guarantees in the ethdev API against such behavior.
Add a notice against using locks in those callbacks.
Bugzilla ID: 1337
Signed-off-by: David Marchand
---
lib/ethdev/rte_ethdev.h | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 21e3a21903..5c6b104fb4 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -4090,7 +4090,19 @@ enum rte_eth_event_type {
RTE_ETH_EVENT_MAX /**< max value of this enum */
};
-/** User application callback to be registered for interrupts. */
+/**
+ * User application callback to be registered for interrupts.
+ *
+ * Note: there is no guarantee in the DPDK drivers that a callback won't be
+ * called in the middle of other parts of the ethdev API. For example,
+ * imagine that thread A calls rte_eth_dev_start() and as part of this
+ * call, a RTE_ETH_EVENT_INTR_RESET event gets generated and the
+ * associated callback is ran on thread A. In that example, if the
+ * application protects its internal data using locks before calling
+ * rte_eth_dev_start(), and the callback takes a same lock, a deadlock
+ * occurs. Because of this, it is highly recommended NOT to take locks in
+ * those callbacks.
+ */
typedef int (*rte_eth_dev_cb_fn)(uint16_t port_id,
enum rte_eth_event_type event, void *cb_arg, void *ret_param);
--
2.43.0
RE: [EXT] [PATCH v2] app/test-crypto-perf: fix invalid mbuf next operation
> In fill_multi_seg_mbuf(), when remaining_segments is 0,
> rte_mbuf m's next should pointer to NULL instead of a
> new rte_mbuf, that causes setting m->next as NULL out
> of the while loop to the invalid mbuf.
>
> This commit fixes the invalid mbuf next operation.
>
> Fixes: bf9d6702eca9 ("app/crypto-perf: use single mempool")
>
> Signed-off-by: Suanming Mou
Cc: sta...@dpdk.org
Applied to dpdk-next-crypto
Thanks.
RE: [EXT] [PATCH v2 1/2] app/test-crypto-perf: fix invalid memcmp results
> The function memcmp() returns an integer less than, equal to,
> or greater than zero. In current code, if the first memcmp()
> returns less than zero and the second memcmp() returns greater
> than zero, the sum of results may still be 0 and indicates
> verify succussed.
>
> This commit converts the return value to be zero or greater
> than zero. That will make sure the sum of results be correct.
>
> Fixes: df52cb3b6e13 ("app/crypto-perf: move verify as single test type")
>
> Signed-off-by: Suanming Mou
> Acked-by: Anoob Joseph
Cc: sta...@dpdk.org
Series
Applied to dpdk-next-crypto
Re: [PATCH 2/2] drivers: RTE_LOG_DP newline consistency
On Wed, Jan 24, 2024 at 5:29 PM Stephen Hemminger wrote: > > Make sure use of RTE_LOG_DP has newline just like uses of RTE_LOG. > > Signed-off-by: Stephen Hemminger I have one concern with this patch. Changing those internal macros means that future backports calling them will introduce issues in the LTS branches. This was the reason I went though the trouble of renaming macros in libraries in my previous series. -- David Marchand
Re: [PATCH v2] lib: remove duplicate prefix in logs
On Thu, Jan 25, 2024 at 1:56 PM David Marchand
wrote:
>
> RTE_LOG() macros prefixe the log messages based on the logtype.
> This results in logs like:
>
> TMTY: TELEMETRY: Attempting socket bind to path '/run/user/...'
> TMTY: TELEMETRY: Socket creation and binding ok
> TMTY: TELEMETRY: Telemetry initialized ok
>
> Remove redundancy in some libraries following their conversion to
> RTE_LOG/RTE_LOG_LINE.
>
> Note: for consistency, dmadev logs are now prefixed with "DMADEV: "
> instead of a too generic "dma: ".
>
> Fixes: 97433132c2ed ("lib: use per line logging in helpers")
> Fixes: 0e21c7c07d62 ("lib: replace logging helpers")
>
> Reported-by: Thomas Monjalon
> Signed-off-by: David Marchand
> Acked-by: Morten Brørup
> Acked-by: Ciara Power
> Reviewed-by: Chengwen Feng
Applied, thanks.
--
David Marchand
Re: [PATCH] net/iavf: fix application reset callback calls
On Wed, Jan 17, 2024 at 12:54 PM David Marchand
wrote:
>
> Don't trigger an application reset callback if the port is not started.
>
> Bugzilla ID: 1337
> Fixes: 675a104e2e94 ("net/iavf: fix abnormal disable HW interrupt")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand
I am withdrawing this patch.
As I mentionned in the bugzilla, this patch is probably introducing races.
I don't have the time/expertise to look deeper into this driver, and
it does not seem like Intel will invest in fixing this.
Fyi, I sent a patch on the ethdev API recommending not to use locks in
application event callbacks.
Reviews welcome.
Thanks.
--
David Marchand
RE: [EXT] Re: [PATCH] test/security: add inline IPsec Rx inject test
> -Original Message-
> From: Stephen Hemminger
> Sent: Friday, January 19, 2024 10:26 PM
> To: Rahul Bhansali
> Cc: dev@dpdk.org; Akhil Goyal ; Anoob Joseph
>
> Subject: [EXT] Re: [PATCH] test/security: add inline IPsec Rx inject test
>
> External Email
>
> --
> On Fri, 19 Jan 2024 11:42:20 +0530
> Rahul Bhansali wrote:
>
> > +static int
> > +test_ipsec_with_rx_inject(struct ip_pkt_vector *vector, const struct
> > +ipsec_test_flags *flags) {
> > + struct rte_security_session_conf sess_conf_out = {0};
> > + struct rte_security_session_conf sess_conf_in = {0};
> > + uint32_t nb_tx, burst_sz, nb_sent = 0, nb_inj = 0;
> > + void *out_ses[ENCAP_DECAP_BURST_SZ] = {0};
> > + void *in_ses[ENCAP_DECAP_BURST_SZ] = {0};
> > + struct rte_crypto_sym_xform cipher_out = {0};
> > + struct rte_crypto_sym_xform cipher_in = {0};
> > + struct rte_crypto_sym_xform auth_out = {0};
> > + struct rte_crypto_sym_xform aead_out = {0};
> > + struct rte_crypto_sym_xform auth_in = {0};
> > + struct rte_crypto_sym_xform aead_in = {0};
> > + uint32_t i, j, nb_rx = 0, nb_inj_rx = 0;
> > + struct rte_mbuf **inj_pkts_burst;
> > + struct ipsec_test_data sa_data;
> > + uint32_t ol_flags;
> > + bool outer_ipv4;
> > + int ret = 0;
> > + void *ctx;
> > +
> > + inj_pkts_burst = (struct rte_mbuf **)rte_calloc("inj_buff",
> > + MAX_TRAFFIC_BURST,
> > + sizeof(void *),
> > + RTE_CACHE_LINE_SIZE);
>
> Why use rte_calloc(), instead of calloc() this is a test and the buffer does
> not need
> to be shared it is on stack.
>
> Cast is not necessary here, calloc and rte_calloc return void *
>
Ack, will send v2.
> > + if (!inj_pkts_burst)
> > + return TEST_FAILED;
> > +
> > + burst_sz = vector->burst ? ENCAP_DECAP_BURST_SZ : 1;
> > + nb_tx = burst_sz;
> > +
> > + memset(tx_pkts_burst, 0, sizeof(tx_pkts_burst[0]) * nb_tx);
> > + memset(rx_pkts_burst, 0, sizeof(rx_pkts_burst[0]) * nb_tx);
> > + memset(inj_pkts_burst, 0, sizeof(inj_pkts_burst[0]) * nb_tx);
>
> calloc routines return already zero'd buffer
Re: [PATCH v3 0/3] Improve optional lib support
On Wed, Dec 20, 2023 at 3:22 PM Bruce Richardson wrote: > > This patchset builds on the previous v1 and v2, and the discussion > which followed about what libraries should be optional. While still > a long way to go from the position suggested in the v2 discussion, > this set moves us a bit further along the road. > > The first patch is a direct v3 from previous versions, changing the > tracking from a list of optional libs to a list of mandatory ones. > The second patch then knocks off another 5 libs off the mandatory > list - all are libs which should have few dependencies in other > components, but which some common sample apps like l3fwd depend upon. > It should be possible to make other libs optional in future, but to > do so likely requires code-changes to #ifdef out support in places. > > To that end, patch 3 is an RFC to add support for "optional libs" to > the build system. For now, nothing uses this, but it may be useful if > someone does want to take on the task of removing a hard dependency > from one component on another and making it optional. > > Bruce Richardson (3): > build: track mandatory rather than optional libs > build: remove 5 libs from mandatory list > build: RFC - add support for optional dependencies I was not sure if I should take the third patch, but the two others make sense to me and I applied them. The third one can be reconsidered when the need arises. Thanks Bruce. -- David Marchand
Re: [PATCH 2/2] app/graph: fix build reason
On Wed, Jan 31, 2024 at 6:46 PM David Marchand
wrote:
>
> When a component is disabled, the reason meson variable must be set to
> provide an explanation why.
>
> Since epoll is a Linux thing, report that the graph application is only
> supported on Linux.
>
> Fixes: 5b21ffb23308 ("app/graph: add CLI framework")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand
> ---
> app/graph/meson.build | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/app/graph/meson.build b/app/graph/meson.build
> index 5b0f966d99..8aefdf505c 100644
> --- a/app/graph/meson.build
> +++ b/app/graph/meson.build
> @@ -5,6 +5,7 @@
> name = 'graph'
> build = cc.has_header('sys/epoll.h')
> if not build
> +reason = 'only supported on Linux'
> subdir_done()
> endif
>
Series applied, thanks.
--
David Marchand
Re: [PATCH v3 0/3] Improve optional lib support
On Thu, Feb 01, 2024 at 10:23:40AM +0100, David Marchand wrote: > On Wed, Dec 20, 2023 at 3:22 PM Bruce Richardson > wrote: > > > > This patchset builds on the previous v1 and v2, and the discussion > > which followed about what libraries should be optional. While still > > a long way to go from the position suggested in the v2 discussion, > > this set moves us a bit further along the road. > > > > The first patch is a direct v3 from previous versions, changing the > > tracking from a list of optional libs to a list of mandatory ones. > > The second patch then knocks off another 5 libs off the mandatory > > list - all are libs which should have few dependencies in other > > components, but which some common sample apps like l3fwd depend upon. > > It should be possible to make other libs optional in future, but to > > do so likely requires code-changes to #ifdef out support in places. > > > > To that end, patch 3 is an RFC to add support for "optional libs" to > > the build system. For now, nothing uses this, but it may be useful if > > someone does want to take on the task of removing a hard dependency > > from one component on another and making it optional. > > > > Bruce Richardson (3): > > build: track mandatory rather than optional libs > > build: remove 5 libs from mandatory list > > build: RFC - add support for optional dependencies > > I was not sure if I should take the third patch, but the two others > make sense to me and I applied them. > The third one can be reconsidered when the need arises. > Yep, agreed. Thanks. /Bruce
Re: [PATCH 1/2] drivers: remove unnecessary RTE_LOG_DP macros
On Wed, Jan 24, 2024 at 5:29 PM Stephen Hemminger wrote: > > Several drivers did copy/paste of log macros for datapath > but are not using them, so remove them. > > Signed-off-by: Stephen Hemminger I applied this first patch for now. Thanks. -- David Marchand
Re: [PATCH v2 11/11] eventdev: RFC clarify docs on event object fields
On Fri, Jan 19, 2024 at 05:43:46PM +, Bruce Richardson wrote:
> Clarify the meaning of the NEW, FORWARD and RELEASE event types.
> For the fields in "rte_event" struct, enhance the comments on each to
> clarify the field's use, and whether it is preserved between enqueue and
> dequeue, and it's role, if any, in scheduling.
>
> Signed-off-by: Bruce Richardson
> ---
>
> As with the previous patch, please review this patch to ensure that the
> expected semantics of the various event types and event fields have not
> changed in an unexpected way.
> ---
> lib/eventdev/rte_eventdev.h | 105 ++--
> 1 file changed, 77 insertions(+), 28 deletions(-)
>
> #define RTE_EVENT_OP_RELEASE2
> /**< Release the flow context associated with the schedule type.
> *
> - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ATOMIC*
> + * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_ATOMIC
> * then this function hints the scheduler that the user has completed
> critical
> * section processing in the current atomic context.
> * The scheduler is now allowed to schedule events from the same flow from
> @@ -1442,21 +1446,19 @@ struct rte_event_vector {
> * performance, but the user needs to design carefully the split into
> critical
> * vs non-critical sections.
> *
> - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ORDERED*
> - * then this function hints the scheduler that the user has done all that
> need
> - * to maintain event order in the current ordered context.
> - * The scheduler is allowed to release the ordered context of this port and
> - * avoid reordering any following enqueues.
> - *
> - * Early ordered context release may increase parallelism and thus system
> - * performance.
Before I do up a V3 of this patchset, I'd like to try and understand a bit
more what was meant by the original text for reordered here. The use of
"context" is very ambiguous, since it could refer to a number of different
things here.
For me, RELEASE for ordered queues should mean much the same as for atomic
queues - it means that the event being released is to be "dropped" from the
point of view of the eventdev scheduler - i.e. any atomic locks held for
that event should be released, and any reordering slots for it should be
skipped. However, the text above seems to imply that when we release one
event it means that we should stop reordering all subsequent events for
that port - which seems wrong to me. Especially in the case where
reordering may be done per flow, does one release mean that we need to go
through all flows and mark as skipped all reordered slots awaiting returned
events from that port? If this is what is intended, how is it better than
just doing another dequeue call from the port, which releases everything
automatically anyway?
Jerin, I believe you were the author of the original text, can you perhaps
clarify? Other PMD maintainers, can any of you chime in with current
supported behaviour when enqueuing a release of an ordered event?
Ideally, I'd like to see this simplified whereby release for ordered
behaves like that for atomic, and refers to the current event only, (and
drop any mention of contexts).
Thanks,
/Bruce
Re: [PATCH] drivers: use dedicated logtypes
On Mon, Dec 18, 2023 at 2:59 PM David Marchand
wrote:
>
> When a driver dedicated logtype exists, use it instead of the generic
> PMD logtype.
>
> This has been done partially automatically with:
>
> $ for file in $(git grep -l RTE_LOG.*PMD.*fmt drivers/'**.h' \
> :^drivers/common/cnxk/roc_platform.h)
> do
> tail=${file#drivers/*/*/}
> dir=${file%%$tail}
> ! git grep -q RTE_LOGTYPE_ $dir || \
> { echo $dir already done; continue; }
> git grep -hE '^extern int .*log.*;$' $file | \
> sed -ne 's/^extern int \([^ ;]*\);$/\1/p' | \
> while read logtype
> do
> git grep -q 'RTE_LOG_REGISTER\(_DEFAULT\|\)('$logtype',' || \
> [ "$logtype" != "${logtype%%driver}" ] || \
> { echo Skipped $logtype; continue; }
> abbrev=$(echo $logtype | sed -e 's/_logtype//' | tr '[a-z]' '[A-Z]')
> sed -i -e 's/^\(extern int '$logtype'.*\)$/\1\n#define RTE_LOGTYPE_' \
> $abbrev' '$logtype'/' $file
> sed -i -e 's/\(RTE_LOG.*, \)PMD,/\1'$abbrev',/' $file
> break
> done
> done
>
> Then a manual update for:
> - common/cpt,
> - common/dpaax,
> - common/idpf,
> - mempool/dpaa,
> - net/bnxt,
> - net/octeon_ep,
> - raw/ifpga,
> - vdpa/ifc,
>
> Signed-off-by: David Marchand
Rebased and applied, thanks.
--
David Marchand
[PATCH v2] app/testpmd: support updating flow rule actions
"flow actions_update" updates a flow rule specified by a rule ID with a
new action list by making a call to "rte_flow_actions_update()":
flow actions_update {port_id} {rule_id}
actions {action} [/ {action} [...]] / end [user_id]
Creating, updating and destroying a flow rule:
testpmd> flow create 0 group 1 pattern eth / end actions drop / end
Flow rule #0 created
testpmd> flow actions_update 0 0 actions queue index 1 / end
Flow rule #0 updated with new actions
testpmd> flow destroy 0 rule 0
Flow rule #0 destroyed
Signed-off-by: Oleksandr Kolomeiets
Reviewed-by: Mykola Kostenok
Reviewed-by: Christian Koue Muf
---
v2:
* No changes.
---
.mailmap| 3 ++
app/test-pmd/cmdline.c | 4 ++
app/test-pmd/cmdline_flow.c | 34 +++-
app/test-pmd/config.c | 43
app/test-pmd/testpmd.h | 3 ++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 44 +
6 files changed, 130 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index 6011526cae..44da31c1c2 100644
--- a/.mailmap
+++ b/.mailmap
@@ -232,6 +232,7 @@ Chintu Hetam
Choonho Son
Chris Metcalf
Christian Ehrhardt
+Christian Koue Muf
Christian Maciocco
Christophe Fontaine
Christophe Grosse
@@ -986,6 +987,7 @@ Mukesh Dua
Murphy Yang
Murthy NSSR
Muthurajan Jayakumar
+Mykola Kostenok
Nachiketa Prachanda
Nagadheeraj Rottela
Naga Harish K S V
@@ -1040,6 +1042,7 @@ Odi Assli
Ognjen Joldzic
Ola Liljedahl
Oleg Polyakov
+Oleksandr Kolomeiets
Olga Shern
Olivier Gournet
Olivier Matz
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index f704319771..8249e4eb92 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -852,6 +852,10 @@ static void cmd_help_long_parsed(void *parsed_result,
"flow destroy {port_id} rule {rule_id} [...]\n"
"Destroy specific flow rules.\n\n"
+ "flow actions_update {port_id} {rule_id}"
+ " actions {action} [/ {action} [...]] / end [user_id]\n"
+ "Update a flow rule with new actions.\n\n"
+
"flow flush {port_id}\n"
"Destroy all flow rules.\n\n"
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 359c187b3c..0af8d13121 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -91,6 +91,7 @@ enum index {
VALIDATE,
CREATE,
DESTROY,
+ ACTIONS_UPDATE,
FLUSH,
DUMP,
QUERY,
@@ -250,6 +251,7 @@ enum index {
VC_TUNNEL_SET,
VC_TUNNEL_MATCH,
VC_USER_ID,
+ VC_IS_USER_ID,
/* Dump arguments */
DUMP_ALL,
@@ -3084,6 +3086,7 @@ static const struct token token_list[] = {
VALIDATE,
CREATE,
DESTROY,
+ ACTIONS_UPDATE,
FLUSH,
DUMP,
LIST,
@@ -3888,6 +3891,17 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY(struct buffer, port)),
.call = parse_destroy,
},
+ [ACTIONS_UPDATE] = {
+ .name = "actions_update",
+ .help = "update a flow rule with new actions",
+ .next = NEXT(NEXT_ENTRY(VC_IS_USER_ID, END),
+NEXT_ENTRY(ACTIONS),
+NEXT_ENTRY(COMMON_RULE_ID),
+NEXT_ENTRY(COMMON_PORT_ID)),
+ .args = ARGS(ARGS_ENTRY(struct buffer, args.vc.rule_id),
+ARGS_ENTRY(struct buffer, port)),
+ .call = parse_vc,
+ },
[FLUSH] = {
.name = "flush",
.help = "destroy all flow rules",
@@ -4134,6 +4148,11 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY(struct buffer, args.vc.user_id)),
.call = parse_vc,
},
+ [VC_IS_USER_ID] = {
+ .name = "user_id",
+ .help = "rule identifier is user-id",
+ .call = parse_vc,
+ },
/* Validate/create pattern. */
[ITEM_PATTERN] = {
.name = "pattern",
@@ -8083,8 +8102,13 @@ parse_vc(struct context *ctx, const struct token *token,
if (!out->command) {
if (ctx->curr != VALIDATE && ctx->curr != CREATE &&
ctx->curr != PATTERN_TEMPLATE_CREATE &&
- ctx->curr != ACTIONS_TEMPLATE_CREATE)
+ ctx->curr != ACTIONS_TEMPLATE_CREATE &&
+ ctx->curr != ACTIONS_UPDATE)
return -1;
+ if (ctx->curr == ACTIONS_UPDATE)
+
[PATCH v5 0/2] multiple representors in one device
Following series adds support to enable creation of multiple representors under one base device. There may be scenarios where port representors for multiple PFs or VFs under PF are required and all these representor ports created under a single pci device. Marvell CNXK port representor solution is designed around this scenario where all representors are backed by a single switch device. Earlier this change was implemented as part of the Marvell CNXK port representor series but after suggestions from Thomas we would like to propose these changes in common code. https://patches.dpdk.org/project/dpdk/patch/20231219174003.72901-25-hka...@marvell.com/#166785 V5: - Added test cases to demonstrate valid and invalid cases - changed the tokenizing logic to address all valid cases V4: - Used MT safe strtok_r in place of strtok - Reworded some comments V3: - Fix duplicate representor devarg key handling logic V2: - Updated the multiple representor devarg pattern to list i.e. representor=[pf[0-1],pf2vf[1,2-3],[4-5]] - Introduced size of array as third argument to rte_eth_devargs_parse() to avoid array corruption - Squashed separate document patch Harman Kalra (2): ethdev: parsing multiple representor devargs string test/devargs: add eth devargs parse cases app/test/test_devargs.c | 107 +++ doc/guides/prog_guide/poll_mode_drv.rst | 4 +- .../prog_guide/switch_representation.rst | 1 + drivers/net/bnxt/bnxt_ethdev.c| 4 +- drivers/net/enic/enic_ethdev.c| 4 +- drivers/net/i40e/i40e_ethdev.c| 4 +- drivers/net/ice/ice_dcf_ethdev.c | 4 +- drivers/net/ixgbe/ixgbe_ethdev.c | 4 +- drivers/net/mlx5/linux/mlx5_os.c | 8 +- .../net/nfp/flower/nfp_flower_representor.c | 4 +- drivers/net/sfc/sfc_ethdev.c | 4 +- lib/ethdev/ethdev_driver.c| 175 -- lib/ethdev/ethdev_driver.h| 9 +- 13 files changed, 296 insertions(+), 36 deletions(-) -- 2.18.0
[PATCH v5 2/2] test/devargs: add eth devargs parse cases
Adding new eth devargs parsing test cases which can demonstrate
valid and invalid usage of devargs patterns.
Signed-off-by: Harman Kalra
---
app/test/test_devargs.c | 107
1 file changed, 107 insertions(+)
diff --git a/app/test/test_devargs.c b/app/test/test_devargs.c
index f977d8..4166b2bea2 100644
--- a/app/test/test_devargs.c
+++ b/app/test/test_devargs.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -201,6 +202,106 @@ test_invalid_devargs(void)
return fail;
}
+struct devargs_parse_case {
+ const char *devargs;
+ uint8_t devargs_count;
+};
+
+static int
+test_valid_devargs_parsing(void)
+{
+ static const struct devargs_parse_case list[] = {
+ /* Single representors patterns */
+ {"representor=1", 1},
+ {"representor=[1,2,3]", 1},
+ {"representor=[0-3,5,7]", 1},
+ {"representor=vf[0-1]", 1},
+ {"representor=sf[0-1]", 1},
+ {"representor=pf1vf[0-1]", 1},
+ {"representor=pf[0-1]vf[1-2]", 1},
+ {"representor=pf[0-1]sf[1-2]", 1},
+ {"representor=c0pf[0-1]", 1},
+ {"representor=sf[1,2]vf[2]", 1}, /* Only SF ports will be
represented */
+ {"representor=vf2sf[1-2]", 1},/* Only VF ports will be
represented */
+ {"representor=c[0-1]pf[0-1]vf[1-2]", 1},
+ /* Single devarg inside multiple representor pattern */
+ {"representor=[c[0-1]pf[0-1]vf[1-2]]", 1},
+ /* Multiple representors patterns */
+ {"representor=[vf0,3]", 2},
+ {"representor=[vf0,vf1]", 2},
+ {"representor=[vf[0],vf[1]]", 2},
+ {"representor=[vf[0,1],3]", 2},
+ {"representor=[vf[0,1],[3]]", 2},
+ {"representor=[pf1vf[0-1],3]", 2},
+ {"representor=[pf1vf[0-1],pf[0-1]]", 2},
+ {"representor=[pf1,pf3,pf1vf[0-1],vf[0],vf[1],vf0,vf1,vf2]", 8},
+
{"representor=[1,3,5,pf1,pf2,pf3,pf1vf[0-1],vf[0],vf[1],vf0,vf1,vf2]", 12},
+
{"representor=[[1,3,5],pf1,pf2,pf3,pf1vf[0-1],vf[0],vf[1],vf0,vf1,vf2]", 10},
+
{"representor=[c[0,2-4]pf[1,6]vf[0-1],vf[0],vf4,[3-5,7],pf1vf[0-1,6],pf[2,4,6]]",
6}
+ };
+ struct rte_eth_devargs eth_da[RTE_MAX_ETHPORTS];
+ uint32_t i;
+ int ret;
+ int fail = 0;
+
+ for (i = 0; i < RTE_DIM(list); i++) {
+ memset(eth_da, 0, RTE_MAX_ETHPORTS * sizeof(*eth_da));
+ ret = rte_eth_devargs_parse(list[i].devargs, eth_da,
RTE_MAX_ETHPORTS);
+ if (ret <= 0) {
+ printf("rte_devargs_parse(%s) returned %d (but should
not)\n",
+ list[i].devargs, ret);
+ fail = ret;
+ break;
+ }
+
+ /* Check the return value, count should be equivalent to no of
devargs. */
+ if (ret != list[i].devargs_count) {
+ printf("Devargs returned count %d != expected count
%d\n", ret,
+ list[i].devargs_count);
+ fail = -1;
+ break;
+ }
+ }
+ return fail;
+}
+
+static int
+test_invalid_devargs_parsing(void)
+{
+ static const char * const list[] = {
+ "representor=1,2,3,4", /* Out [] missing */
+ "representor=[1 2 3]", /* , missing */
+ "representor=c[1,2]", /* Only controller no
valid */
+ "representor=c0vf[0-1]",/* Controller with vf
alone not valid */
+ "representor=c0sf[0-1]",/* Controller with sf
alone not valid */
+ "representor=vf[0-1],vf3", /* Out [] missing */
+ "representor=[[vf0,3]]",/* Double [] is invalid
*/
+ "representor=pfvf[1-2]",/* No PF index provided
*/
+ "representor=pf1[vf[1-2]]", /* Additional [] across
vf */
+ "representor=c0[pf1vf[1-2]]", /* Additional [] across
pfvf */
+ "representor=c0[pf1[vf[1-2]]]", /* Additional [] across
pfvf */
+ "representor=[pf1vf[0-1], pf[0-1]]",/* Space between two
devargs is invalid */
+ "representor=[pf1vf[0-1], 3]", /* Space between two
devargs is invalid */
+ "representor=pf1vf[1-2],representor=1", /* Multiple representor
keys */
+ };
+ struct rte_eth_devargs eth_da[RTE_MAX_ETHPORTS];
+ uint32_t i;
+ int ret;
+ int fail = 0;
+
+ for (i = 0; i < RTE_DIM(list); i++) {
+ memset(eth_da, 0, RTE_MAX_ETHPORTS * sizeof(*eth_da));
+ ret = rte_eth_devargs_parse(lis
[PATCH v5 1/2] ethdev: parsing multiple representor devargs string
Adding support for parsing multiple representor devargs strings
passed to a PCI BDF. There may be scenario where port representors
for various PFs or VFs under PFs are required and all these are
representor ports shall be backed by single pci device. In such
case port representors can be created using devargs string:
,representor=[pf[0-1],pf2vf[1,2-3],[4-5]]
Signed-off-by: Harman Kalra
---
doc/guides/prog_guide/poll_mode_drv.rst | 4 +-
.../prog_guide/switch_representation.rst | 1 +
drivers/net/bnxt/bnxt_ethdev.c| 4 +-
drivers/net/enic/enic_ethdev.c| 4 +-
drivers/net/i40e/i40e_ethdev.c| 4 +-
drivers/net/ice/ice_dcf_ethdev.c | 4 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 4 +-
drivers/net/mlx5/linux/mlx5_os.c | 8 +-
.../net/nfp/flower/nfp_flower_representor.c | 4 +-
drivers/net/sfc/sfc_ethdev.c | 4 +-
lib/ethdev/ethdev_driver.c| 175 --
lib/ethdev/ethdev_driver.h| 9 +-
12 files changed, 189 insertions(+), 36 deletions(-)
diff --git a/doc/guides/prog_guide/poll_mode_drv.rst
b/doc/guides/prog_guide/poll_mode_drv.rst
index c145a9066c..5008b41c60 100644
--- a/doc/guides/prog_guide/poll_mode_drv.rst
+++ b/doc/guides/prog_guide/poll_mode_drv.rst
@@ -376,7 +376,7 @@ parameters to those ports.
* ``representor`` for a device which supports the creation of representor ports
this argument allows user to specify which switch ports to enable port
- representors for. Multiple representors in one device argument is invalid::
+ representors for::
-a DBDF,representor=vf0
-a DBDF,representor=vf[0,4,6,9]
@@ -389,6 +389,8 @@ parameters to those ports.
-a DBDF,representor=pf1vf0
-a DBDF,representor=pf[0-1]sf[0-127]
-a DBDF,representor=pf1
+ -a DBDF,representor=[pf[0-1],pf2vf[0-2],pf3[3,5-8]]
+ (Multiple representors in one device argument can be represented as a list)
Note: PMDs are not required to support the standard device arguments and users
should consult the relevant PMD documentation to see support devargs.
diff --git a/doc/guides/prog_guide/switch_representation.rst
b/doc/guides/prog_guide/switch_representation.rst
index 6fd7b98bdc..46e0ca85a5 100644
--- a/doc/guides/prog_guide/switch_representation.rst
+++ b/doc/guides/prog_guide/switch_representation.rst
@@ -77,6 +77,7 @@ thought as a software "patch panel" front-end for
applications.
-a pci:dbdf,representor=sf1
-a pci:dbdf,representor=sf[0-1023]
-a pci:dbdf,representor=sf[0,2-1023]
+ -a pci:dbdf,representor=[pf[0-1],pf2vf[0-2],pf3[3,5]]
- As virtual devices, they may be more limited than their physical
counterparts, for instance by exposing only a subset of device
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index acf7e6e46e..5d4f599044 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -6383,8 +6383,8 @@ static int bnxt_pci_probe(struct rte_pci_driver *pci_drv
__rte_unused,
if (pci_dev->device.devargs) {
ret = rte_eth_devargs_parse(pci_dev->device.devargs->args,
- ð_da);
- if (ret)
+ ð_da, 1);
+ if (ret < 0)
return ret;
}
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index b04b6c9aa1..33d96ec07a 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -1317,8 +1317,8 @@ static int eth_enic_pci_probe(struct rte_pci_driver
*pci_drv __rte_unused,
ENICPMD_FUNC_TRACE();
if (pci_dev->device.devargs) {
retval = rte_eth_devargs_parse(pci_dev->device.devargs->args,
- ð_da);
- if (retval)
+ ð_da, 1);
+ if (retval < 0)
return retval;
}
if (eth_da.nb_representor_ports > 0 &&
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 3ca226156b..4d21341382 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -646,8 +646,8 @@ eth_i40e_pci_probe(struct rte_pci_driver *pci_drv
__rte_unused,
if (pci_dev->device.devargs) {
retval = rte_eth_devargs_parse(pci_dev->device.devargs->args,
- ð_da);
- if (retval)
+ ð_da, 1);
+ if (retval < 0)
return retval;
}
diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index 5d845bba31..0e991fe4b8 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -2041,8 +2041,8 @@ eth_ice_dcf_pci_probe(__rte_unused struct rte_pci_driver
*pci_drv,
if (!ice_devargs_check(pci_dev->devic
[PATCH v2] test/security: add inline IPsec Rx inject test
Add test for inline IPsec Rx inject verification. This test case
will inject the known vector to crypto HW from ethdev and
verifies it back with decrypted packet from ethdev Rx.
Signed-off-by: Rahul Bhansali
---
Changes in v2: Addressed review comments of Stephen Hemminger
app/test/test_security_inline_proto.c | 315 ++
app/test/test_security_inline_proto_vectors.h | 27 ++
2 files changed, 342 insertions(+)
diff --git a/app/test/test_security_inline_proto.c
b/app/test/test_security_inline_proto.c
index 78a2064b65..c85ee3f51d 100644
--- a/app/test/test_security_inline_proto.c
+++ b/app/test/test_security_inline_proto.c
@@ -829,6 +829,222 @@ verify_inbound_oop(struct ipsec_test_data *td,
return ret;
}
+static int
+test_ipsec_with_rx_inject(struct ip_pkt_vector *vector, const struct
ipsec_test_flags *flags)
+{
+ struct rte_security_session_conf sess_conf_out = {0};
+ struct rte_security_session_conf sess_conf_in = {0};
+ uint32_t nb_tx, burst_sz, nb_sent = 0, nb_inj = 0;
+ struct rte_crypto_sym_xform cipher_out = {0};
+ struct rte_crypto_sym_xform cipher_in = {0};
+ struct rte_crypto_sym_xform auth_out = {0};
+ struct rte_crypto_sym_xform aead_out = {0};
+ struct rte_crypto_sym_xform auth_in = {0};
+ struct rte_crypto_sym_xform aead_in = {0};
+ void *out_ses[ENCAP_DECAP_BURST_SZ] = {0};
+ void *in_ses[ENCAP_DECAP_BURST_SZ] = {0};
+ uint32_t i, j, nb_rx = 0, nb_inj_rx = 0;
+ struct rte_mbuf **inj_pkts_burst;
+ struct ipsec_test_data sa_data;
+ uint32_t ol_flags;
+ bool outer_ipv4;
+ int ret = 0;
+ void *ctx;
+
+ inj_pkts_burst = calloc(MAX_TRAFFIC_BURST, sizeof(void *));
+ if (!inj_pkts_burst)
+ return TEST_FAILED;
+
+ burst_sz = vector->burst ? ENCAP_DECAP_BURST_SZ : 1;
+ nb_tx = burst_sz;
+
+ memcpy(&sa_data, vector->sa_data, sizeof(struct ipsec_test_data));
+ sa_data.ipsec_xform.direction = RTE_SECURITY_IPSEC_SA_DIR_EGRESS;
+ outer_ipv4 = is_outer_ipv4(&sa_data);
+
+ for (i = 0; i < nb_tx; i++) {
+ tx_pkts_burst[i] = init_packet(mbufpool, vector->full_pkt->data,
+ vector->full_pkt->len,
outer_ipv4);
+ if (tx_pkts_burst[i] == NULL) {
+ ret = -1;
+ printf("\n packed init failed\n");
+ goto out;
+ }
+ }
+
+ for (i = 0; i < burst_sz; i++) {
+ memcpy(&sa_data, vector->sa_data, sizeof(struct
ipsec_test_data));
+ /* Update SPI for every new SA */
+ sa_data.ipsec_xform.spi += i;
+ sa_data.ipsec_xform.direction =
RTE_SECURITY_IPSEC_SA_DIR_EGRESS;
+ if (sa_data.aead) {
+ sess_conf_out.crypto_xform = &aead_out;
+ } else {
+ sess_conf_out.crypto_xform = &cipher_out;
+ sess_conf_out.crypto_xform->next = &auth_out;
+ }
+
+ /* Create Inline IPsec outbound session. */
+ ret = create_inline_ipsec_session(&sa_data, port_id,
&out_ses[i], &ctx, &ol_flags,
+ flags, &sess_conf_out);
+ if (ret) {
+ printf("\nInline outbound session create failed\n");
+ goto out;
+ }
+ }
+
+ for (i = 0; i < nb_tx; i++) {
+ if (ol_flags & RTE_SECURITY_TX_OLOAD_NEED_MDATA)
+ rte_security_set_pkt_metadata(ctx,
+ out_ses[i], tx_pkts_burst[i], NULL);
+ tx_pkts_burst[i]->ol_flags |= RTE_MBUF_F_TX_SEC_OFFLOAD;
+ }
+
+ for (i = 0; i < burst_sz; i++) {
+ memcpy(&sa_data, vector->sa_data, sizeof(struct
ipsec_test_data));
+ /* Update SPI for every new SA */
+ sa_data.ipsec_xform.spi += i;
+ sa_data.ipsec_xform.direction =
RTE_SECURITY_IPSEC_SA_DIR_INGRESS;
+
+ if (sa_data.aead) {
+ sess_conf_in.crypto_xform = &aead_in;
+ } else {
+ sess_conf_in.crypto_xform = &auth_in;
+ sess_conf_in.crypto_xform->next = &cipher_in;
+ }
+ /* Create Inline IPsec inbound session. */
+ ret = create_inline_ipsec_session(&sa_data, port_id,
&in_ses[i], &ctx, &ol_flags,
+ flags, &sess_conf_in);
+ if (ret) {
+ printf("\nInline inbound session create failed\n");
+ goto out;
+ }
+ }
+
+ rte_delay_ms(1);
+ /* Create and receive encrypted packets */
+ if (event_mode_enabled)
+ nb_sent = event_tx_burst(tx_pkts_burst, nb_tx);
+ else
+ nb_se
Re: [PATCH] ethdev: recommend against using locks in event callbacks
On 01/02/2024 08:43, David Marchand wrote:
> As described in a recent bugzilla opened against the net/iavf driver,
> a driver may call a event callback from other calls of the ethdev API.
>
> Nothing guarantees in the ethdev API against such behavior.
>
> Add a notice against using locks in those callbacks.
>
> Bugzilla ID: 1337
>
> Signed-off-by: David Marchand
> ---
> lib/ethdev/rte_ethdev.h | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 21e3a21903..5c6b104fb4 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -4090,7 +4090,19 @@ enum rte_eth_event_type {
> RTE_ETH_EVENT_MAX /**< max value of this enum */
> };
>
> -/** User application callback to be registered for interrupts. */
> +/**
> + * User application callback to be registered for interrupts.
> + *
> + * Note: there is no guarantee in the DPDK drivers that a callback won't be
> + * called in the middle of other parts of the ethdev API. For example,
> + * imagine that thread A calls rte_eth_dev_start() and as part of this
> + * call, a RTE_ETH_EVENT_INTR_RESET event gets generated and the
> + * associated callback is ran on thread A. In that example, if the
> + * application protects its internal data using locks before calling
> + * rte_eth_dev_start(), and the callback takes a same lock, a deadlock
> + * occurs. Because of this, it is highly recommended NOT to take locks
> in
> + * those callbacks.
> + */
That is a good practical recommendation for an application developer.
I wonder if it should taken further so that the API formally states the
callback MUST be non-blocking?
> typedef int (*rte_eth_dev_cb_fn)(uint16_t port_id,
> enum rte_eth_event_type event, void *cb_arg, void *ret_param);
>
RE: [EXT] Re: [PATCH v4 1/1] ethdev: parsing multiple representor devargs string
Hi Ferruh
Please find response inline
> -Original Message-
> From: Ferruh Yigit
> Sent: Wednesday, January 31, 2024 4:40 AM
> To: Harman Kalra ; dev@dpdk.org; Thomas Monjalon
> ; Andrew Rybchenko
> ; Ajit Khaparde
> ; Somnath Kotur
> ; John Daley ; Hyong
> Youb Kim ; Yuying Zhang ;
> Beilei Xing ; Qiming Yang ; Qi
> Zhang ; Wenjun Wu ;
> Dariusz Sosnowski ; Viacheslav Ovsiienko
> ; Ori Kam ; Suanming Mou
> ; Matan Azrad ; Chaoyong
> He
> Subject: Re: [EXT] Re: [PATCH v4 1/1] ethdev: parsing multiple representor
> devargs string
>
> On 1/29/2024 6:20 PM, Harman Kalra wrote:
> > Hi Ferruh
> >
> > Thanks for the review
> > Please find response inline
> >
> >
> >> -Original Message-
> >> From: Ferruh Yigit
> >> Sent: Friday, January 26, 2024 7:13 PM
> >> To: Harman Kalra ; dev@dpdk.org; Thomas
> Monjalon
> >> ; Andrew Rybchenko
> >> ; Ajit Khaparde
> >> ; Somnath Kotur
> >> ; John Daley ;
> Hyong
> >> Youb Kim ; Yuying Zhang
> ;
> >> Beilei Xing ; Qiming Yang
> >> ; Qi Zhang ; Wenjun Wu
> >> ; Dariusz Sosnowski ;
> >> Viacheslav Ovsiienko ; Ori Kam
> >> ; Suanming Mou ; Matan
> Azrad
> >> ; Chaoyong He
> >> Subject: [EXT] Re: [PATCH v4 1/1] ethdev: parsing multiple
> >> representor devargs string
> >>
> >> External Email
> >>
> >> -
> >> - On 1/21/2024 7:19 PM, Harman Kalra wrote:
> >>> Adding support for parsing multiple representor devargs strings
> >>> passed to a PCI BDF. There may be scenario where port representors
> >>> for various PFs or VFs under PFs are required and all these are
> >>> representor ports shall be backed by single pci device. In such case
> >>> port representors can be created using devargs string:
> >>> ,representor=[pf[0-1],pf2vf[1,2-3],[4-5]]
> >>>
> >>
> >> This patch is to be able to parse multiple representor device
> >> argument, but I am concerned how it is used.
> >
> > In Marvell CNXK port representor solution all representors are backed
> > by a single PCI device (we call it as eswitch device). Eswitch device
> > is not DPDK ethdev device but an internal device with NIC capabilities
> > and is configured with as many no of Rxqs and Txqs as port representor
> required.
> > Hence each port representor will have dedicated RxQ/TxQ pair to
> > communicate with respective represented PF or VF.
> >
>
> ack, thanks for clarification.
>
> Just to double check, is the cnxk driver support of new syntax planned for
> this
> release?
> It helps if the RFC is out before merging this patch.
Yes, it is planned for this release. We have already pushed 2 versions and
received
comments. V3 is ready with all V2 comments addressed, I will push by EOD.
>
> >
> >>
> >> When there are multiple representor ports backed up by same device,
> >> can't it cause syncronization issues, like if two representor
> >> interfaces used for conflicting configurations. Or if datapath will
> >> be supported, what if two representator used simultaneously.
> >
> > As I mentioned above, each port representor will have dedicated RxQ
> > and TxQ, worker cores can poll on respective queues without any
> synchronization issue.
> > I hope I am able to explain the use case.
> >
>
> ack
>
> >>
> >>
> >
> >
> >
> >
> >>
> >> Meanwhile please check some comments below related to the parser code.
> >>
> >> <...>
> >>
> >>> @@ -459,9 +460,26 @@ eth_dev_devargs_tokenise(struct rte_kvargs
> >> *arglist, const char *str_in)
> >>> break;
> >>>
> >>> case 3: /* Parsing list */
> >>> - if (*letter == ']')
> >>> - state = 2;
> >>> - else if (*letter == '\0')
> >>> + if (*letter == ']') {
> >>> + /* For devargs having singles lists move to
> >> state 2 once letter
> >>> + * becomes ']' so each can be considered as
> >> different pair key
> >>> + * value. But in nested lists case e.g. multiple
> >> representors
> >>> + * case i.e. [pf[0-3],pfvf[3,4-6]], complete
> >> nested list should
> >>> + * be considered as one pair value, hence
> >> checking if end of outer
> >>> + * list ']' is reached else stay on state 3.
> >>> + */
> >>> + if ((strcmp("representor", pair->key) == 0)
> >>&&
> >>> + (*(letter + 1) != '\0' && *(letter + 2) !=
> >>> '\0'
> >> &&
> >>> + *(letter + 3) != '\0')
> >>> &&
> >>> + ((*(letter + 2) == 'p' && *(letter + 3) ==
> >>> 'f')
> >> ||
> >>> + (*(letter + 2) == 'v' && *(letter + 3) ==
> >>> 'f')
> >> ||
> >>> + (*(letter + 2) == 's' && *(letter + 3) ==
> >>> 'f')
> >> ||
> >>> + (*(letter + 2) == 'c' && isdigit(*(le
Re: [PATCH] cfgfile: increase value length
On Wed, Dec 6, 2023 at 12:31 PM Vipin Varghese wrote:
>
> The default value for CFG_VALUE_LEN is set to 256 characters.
> This limits the parsing for longer strings in configuration file.
> Setting the default to 2048 characters increases the value array
> size in `struct rte_cfgfile_entry`.
>
> Files using cfgfile library are
> 1. drivers/net/mvpp2/
> 2. app/test-dma-perf/
> 3. app/test/
> 4. examples/qos_sched/
>
> The structure `rte_cfgfile_entry` is not included in DPDK libraries.
> Modifying from 256 to 2048 allows `app/test-dma-perf/main.c` helps to
> parse longer string as shared in https://bugs.dpdk.org/show_bug.cgi?id=1333
>
> Signed-off-by: Vipin Varghese
> Suggested-by: Ferruh Yigit
> ---
> lib/cfgfile/rte_cfgfile.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/cfgfile/rte_cfgfile.h b/lib/cfgfile/rte_cfgfile.h
> index 232c65c77b..401353c44e 100644
> --- a/lib/cfgfile/rte_cfgfile.h
> +++ b/lib/cfgfile/rte_cfgfile.h
> @@ -24,7 +24,7 @@ extern "C" {
> #endif
>
> #ifndef CFG_VALUE_LEN
> -#define CFG_VALUE_LEN 256
> +#define CFG_VALUE_LEN 2048
> #endif
>
> /** Configuration file */
Last time I looked at this code, I had the impression such a change
would break the ABI.
I see that the discussion stopped at a suggestion to change some parsing logic.
For now, I marked this patch as Changes requested.
Thanks.
--
David Marchand
Re: [PATCH] app/test: remove ifdefs for cmdline library
On Thu, Dec 14, 2023 at 6:03 PM Tyler Retzlaff wrote: > > On Thu, Dec 14, 2023 at 11:30:21AM +, Bruce Richardson wrote: > > The DPDK unit test binary relies on cmdline library and cannot do > > anything without it being present. As it's a mandatory dependency we can > > remove the ifdefs for it from main.c > > > > Signed-off-by: Bruce Richardson > Acked-by: Tyler Retzlaff Applied, thanks. -- David Marchand
Re: [PATCH] app/test: prevent exiting after skipped test
On Thu, Dec 14, 2023 at 6:04 PM Tyler Retzlaff wrote: > > On Thu, Dec 14, 2023 at 11:38:13AM +, Bruce Richardson wrote: > > When processing a list of tests to run, the loop termination condition > > was a test returning a value != 0. This means that if one of a series of > > tests was skipped, i.e. returned TEST_SKIPPED, the whole execution run > > was stopped. Since a test being skipped is not an error condition, we > > put in an explicit check for that to keep executing any remaining tests. > > > > Signed-off-by: Bruce Richardson > Acked-by: Tyler Retzlaff Applied, thanks. -- David Marchand
Re: [Patch v2] net/mana: use rte_pktmbuf_alloc_bulk for allocating RX WQEs
On 2/1/2024 3:55 AM, Long Li wrote:
'mbufs' is temporarily storage for allocated mbuf pointers, why not
allocate if from stack instead, can be faster and easier to manage:
"struct rte_mbuf *mbufs[count]"
>>>
>>> That would introduce a variable length array.
>>> VLA's should be removed, they are not supported on Windows and many
>>> security tools flag them. The problem is that it makes the code
>>> brittle if count gets huge.
>>>
>>> But certainly regular calloc() or alloca() would work here.
>>>
>>
>> Most of the existing bulk alloc already uses VLA but I can see the problem
>> it is not
>> being supported by Windows.
>>
>> As this mbuf pointer array is short lived within the function, and being in
>> the fast
>> path, I think continuous alloc and free can be prevented,
>>
>> one option can be to define a fixed size, big enough, array which requires
>> additional loop for the cases 'count' size is bigger than array size,
>>
>> or an array can be allocated by driver init in device specific data ,as we
>> know it
>> will be required continuously in the datapath, and it can be freed during
>> device
>> close()/uninit().
>>
>> I think an fixed size array from stack is easier and can be preferred.
>
> I sent a v3 of the patch, still using alloc().
>
> I found two problems with using a fixed array:
> 1. the array size needs to be determined in advance. I don't know what a good
> number should be. If too big, some of them may be wasted. (and maybe make a
> bigger mess of CPU cache) If too small, it ends up doing multiple
> allocations, which is the problem this patch trying to solve.
>
I think default burst size 32 can be used like below:
struct rte_mbuf *mbufs[32];
loop: //use do {} while(); if you prefer
n = min(32, count);
rte_pktmbuf_alloc_bulk(mbufs, n);
for (i = 0; i < n; i++)
mana_post_rx_wqe(rxq, mbufs[i]);
count -= n;
if (count > 0) goto loop:
This additional loop doesn't make code very complex (I think not more
than additional alloc() & free()) and it doesn't waste memory.
I suggest doing a performance measurement with above change, it may
increase performance,
afterwards if you insist to go with original code, we can do it.
> 2. if makes the code slightly more complex ,but I think 1 is the main problem.
>
> I think another approach is to use VLA by default, but for Windows use
> alloc().
>
> Long
Re: [PATCH v3 1/3] ethdev: rename action modify field data structure
On 1/31/2024 2:57 AM, Suanming Mou wrote:
> Hi,
>
>> -Original Message-
>> From: Ferruh Yigit
>> Sent: Wednesday, January 31, 2024 1:19 AM
>> To: Suanming Mou ; Ori Kam ;
>> Aman Singh ; Yuying Zhang
>> ; Dariusz Sosnowski ; Slava
>> Ovsiienko ; Matan Azrad ; NBU-
>> Contact-Thomas Monjalon (EXTERNAL) ; Andrew
>> Rybchenko
>> Cc: dev@dpdk.org
>> Subject: Re: [PATCH v3 1/3] ethdev: rename action modify field data structure
>>
>> On 1/15/2024 9:13 AM, Suanming Mou wrote:
>>> Current rte_flow_action_modify_data struct describes the pkt field
>>> perfectly and is used only in action.
>>>
>>> It is planned to be used for item as well. This commit renames it to
>>> "rte_flow_field_data" making it compatible to be used by item.
>>>
>>
>> ack to rename struct to use in pattern.
>>
>>> Signed-off-by: Suanming Mou
>>> Acked-by: Ori Kam
>>> Acked-by: Andrew Rybchenko
>>> ---
>>> app/test-pmd/cmdline_flow.c| 2 +-
>>> doc/guides/prog_guide/rte_flow.rst | 2 +-
>>> doc/guides/rel_notes/release_24_03.rst | 1 +
>>> drivers/net/mlx5/mlx5_flow.c | 4 ++--
>>> drivers/net/mlx5/mlx5_flow.h | 6 +++---
>>> drivers/net/mlx5/mlx5_flow_dv.c| 10 +-
>>> lib/ethdev/rte_flow.h | 8
>>> 7 files changed, 17 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
>>> index ce71818705..3725e955c7 100644
>>> --- a/app/test-pmd/cmdline_flow.c
>>> +++ b/app/test-pmd/cmdline_flow.c
>>> @@ -740,7 +740,7 @@ enum index {
>>> #define ITEM_RAW_SIZE \
>>> (sizeof(struct rte_flow_item_raw) + ITEM_RAW_PATTERN_SIZE)
>>>
>>> -/** Maximum size for external pattern in struct
>>> rte_flow_action_modify_data. */
>>> +/** Maximum size for external pattern in struct rte_flow_field_data.
>>> +*/
>>> #define ACTION_MODIFY_PATTERN_SIZE 32
>>>
>>
>> What do you think to update 'ACTION_MODIFY_PATTERN_SIZE' here too, instead
>> of next patch?
>
> Agree.
>
>>
>> <...>
>>
>>> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index
>>> affdc8121b..40f6dcaacd 100644
>>> --- a/lib/ethdev/rte_flow.h
>>> +++ b/lib/ethdev/rte_flow.h
>>> @@ -3910,9 +3910,9 @@ enum rte_flow_field_id {
>>> * @warning
>>> * @b EXPERIMENTAL: this structure may change without prior notice
>>> *
>>> - * Field description for MODIFY_FIELD action.
>>> + * Field description for packet field.
>>>
>>
>> New note is not very helpful, how can we make it more useful?
>>
>> Does it make sense to keep 'MODIFY_FIELD' and add 'COMPARE ITEM' in next
>> patch, to clarify the intended usage for the struct, otherwise it is too
>> generic.
>
> OK, sorry, the purpose is to make it generic. So next time if other ITEM or
> ACTION need that field, it can be used directly.
> Otherwise, it feels like it can only be used by 'MODIFY_FIELD' and
> 'COMPARE_ITEM', what do you think?
>
I don't have an intention to limit its usage, but to clarify usage for
whoever checks the document.
"Field description for packet field." doesn't say what exactly it is and
cause confusion.
Perhaps wording can be changed to say two possible usages are for
'MODIFY_FIELD' and 'COMPARE_ITEM'?
Re: [PATCH 00/43] replace strerror
On Wed, Nov 15, 2023 at 1:17 AM Stephen Hemminger wrote: > > On Tue, 14 Nov 2023 16:24:56 +0800 > Dengdui Huang wrote: > > > The function strerror() is insecure in a multi-thread environment. > > This series of patches fix it. In this patchset, only the libs and > > drivers are modified. > > Doing such a global replace seems like a lot of changes for many > cases that are not multi-threaded. > Is there an actual fix mixed somewhere in this series? If so, it should be clearly identified for backports. -- David Marchand
RE: [PATCH v3 1/3] ethdev: rename action modify field data structure
> -Original Message-
> From: Ferruh Yigit
> Sent: Thursday, February 1, 2024 6:56 PM
> To: Suanming Mou ; Ori Kam ;
> Aman Singh ; Yuying Zhang
> ; Dariusz Sosnowski ; Slava
> Ovsiienko ; Matan Azrad ; NBU-
> Contact-Thomas Monjalon (EXTERNAL) ; Andrew
> Rybchenko
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v3 1/3] ethdev: rename action modify field data structure
>
> On 1/31/2024 2:57 AM, Suanming Mou wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Ferruh Yigit
> >> Sent: Wednesday, January 31, 2024 1:19 AM
> >> To: Suanming Mou ; Ori Kam ;
> >> Aman Singh ; Yuying Zhang
> >> ; Dariusz Sosnowski ;
> >> Slava Ovsiienko ; Matan Azrad
> >> ; NBU- Contact-Thomas Monjalon (EXTERNAL)
> >> ; Andrew Rybchenko
> >>
> >> Cc: dev@dpdk.org
> >> Subject: Re: [PATCH v3 1/3] ethdev: rename action modify field data
> >> structure
> >>
> >> On 1/15/2024 9:13 AM, Suanming Mou wrote:
> >>> Current rte_flow_action_modify_data struct describes the pkt field
> >>> perfectly and is used only in action.
> >>>
> >>> It is planned to be used for item as well. This commit renames it to
> >>> "rte_flow_field_data" making it compatible to be used by item.
> >>>
> >>
> >> ack to rename struct to use in pattern.
> >>
> >>> Signed-off-by: Suanming Mou
> >>> Acked-by: Ori Kam
> >>> Acked-by: Andrew Rybchenko
> >>> ---
> >>> app/test-pmd/cmdline_flow.c| 2 +-
> >>> doc/guides/prog_guide/rte_flow.rst | 2 +-
> >>> doc/guides/rel_notes/release_24_03.rst | 1 +
> >>> drivers/net/mlx5/mlx5_flow.c | 4 ++--
> >>> drivers/net/mlx5/mlx5_flow.h | 6 +++---
> >>> drivers/net/mlx5/mlx5_flow_dv.c| 10 +-
> >>> lib/ethdev/rte_flow.h | 8
> >>> 7 files changed, 17 insertions(+), 16 deletions(-)
> >>>
> >>> diff --git a/app/test-pmd/cmdline_flow.c
> >>> b/app/test-pmd/cmdline_flow.c index ce71818705..3725e955c7 100644
> >>> --- a/app/test-pmd/cmdline_flow.c
> >>> +++ b/app/test-pmd/cmdline_flow.c
> >>> @@ -740,7 +740,7 @@ enum index {
> >>> #define ITEM_RAW_SIZE \
> >>> (sizeof(struct rte_flow_item_raw) + ITEM_RAW_PATTERN_SIZE)
> >>>
> >>> -/** Maximum size for external pattern in struct
> >>> rte_flow_action_modify_data. */
> >>> +/** Maximum size for external pattern in struct rte_flow_field_data.
> >>> +*/
> >>> #define ACTION_MODIFY_PATTERN_SIZE 32
> >>>
> >>
> >> What do you think to update 'ACTION_MODIFY_PATTERN_SIZE' here too,
> >> instead of next patch?
> >
> > Agree.
> >
> >>
> >> <...>
> >>
> >>> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index
> >>> affdc8121b..40f6dcaacd 100644
> >>> --- a/lib/ethdev/rte_flow.h
> >>> +++ b/lib/ethdev/rte_flow.h
> >>> @@ -3910,9 +3910,9 @@ enum rte_flow_field_id {
> >>> * @warning
> >>> * @b EXPERIMENTAL: this structure may change without prior notice
> >>> *
> >>> - * Field description for MODIFY_FIELD action.
> >>> + * Field description for packet field.
> >>>
> >>
> >> New note is not very helpful, how can we make it more useful?
> >>
> >> Does it make sense to keep 'MODIFY_FIELD' and add 'COMPARE ITEM' in
> >> next patch, to clarify the intended usage for the struct, otherwise it is
> >> too
> generic.
> >
> > OK, sorry, the purpose is to make it generic. So next time if other ITEM or
> ACTION need that field, it can be used directly.
> > Otherwise, it feels like it can only be used by 'MODIFY_FIELD' and
> 'COMPARE_ITEM', what do you think?
> >
>
> I don't have an intention to limit its usage, but to clarify usage for
> whoever checks
> the document.
>
> "Field description for packet field." doesn't say what exactly it is and cause
> confusion.
>
> Perhaps wording can be changed to say two possible usages are for
> 'MODIFY_FIELD' and 'COMPARE_ITEM'?
Sounds good, OK, I will update.
BTW, I saw the patch apply failed, seems it is due to Raslan's branch has some
extra features than your branch.
So I just want to know is it OK? Or should I still base on your branch? When
will the branches be synced.
Re: [PATCH 00/21] replace strtok with strtok_r
On Tue, Nov 21, 2023 at 4:33 AM Jie Hai wrote: > > On 2023/11/15 23:08, Stephen Hemminger wrote: > > On Wed, 15 Nov 2023 12:27:37 +0100 > > Morten Brørup wrote: > > > just a final follow up, i can see that we already have a rte_strerror > here to do the replace with reentrant dance. it is probably good to > follow the already established pattern for this and have a > >>> rte_strtok. > >>> > >>> +1 for have rte_strtok which could cover different platform. > >> > >> +1 to rte_strtok doing the reentrant dance for us. > >> > >> If we had such an rte_strtok(), we could also generally disallow the use > >> of strtok(). > > > > Good idea, I like this. > > Would be good to have a version on Windows as well. > > > > . > Hi, all maintainers, > > Since the map of strtok_r to strtok_s with three patramaters has > been done in "rte_os_shim.h", I just include this file. > And the rte_strtok is defined as below. > My question is whether the > "strtok_s(s, stringlen, delim, save_ptr)" and > "strtok_s(str, delim, saveptr)" are compatible for C11. > > And I check the glibc codes here, > https://sourceware.org/git/glibc.git > there is no definition of strtok_s, is strtok_s not in use? > > If so, should we delayed processing for the C11 standard strtok_s > function? That is, delete the "#ifdef __STDC_LIB_EXT1__... > #endif" part, but keep the extension of the four parameters for later > use. Or keep the following change but never use stringlen as not null > until the function can be used. > > What do you think? Regardless of how it is done internally, I would not inline this helper. This will minimise headaches with checks against toolchain/compiler support in a DPDK header. -- David Marchand
Re: [PATCH v3 1/3] ethdev: rename action modify field data structure
On 2/1/2024 11:09 AM, Suanming Mou wrote:
>
>
>> -Original Message-
>> From: Ferruh Yigit
>> Sent: Thursday, February 1, 2024 6:56 PM
>> To: Suanming Mou ; Ori Kam ;
>> Aman Singh ; Yuying Zhang
>> ; Dariusz Sosnowski ; Slava
>> Ovsiienko ; Matan Azrad ; NBU-
>> Contact-Thomas Monjalon (EXTERNAL) ; Andrew
>> Rybchenko
>> Cc: dev@dpdk.org
>> Subject: Re: [PATCH v3 1/3] ethdev: rename action modify field data structure
>>
>> On 1/31/2024 2:57 AM, Suanming Mou wrote:
>>> Hi,
>>>
-Original Message-
From: Ferruh Yigit
Sent: Wednesday, January 31, 2024 1:19 AM
To: Suanming Mou ; Ori Kam ;
Aman Singh ; Yuying Zhang
; Dariusz Sosnowski ;
Slava Ovsiienko ; Matan Azrad
; NBU- Contact-Thomas Monjalon (EXTERNAL)
; Andrew Rybchenko
Cc: dev@dpdk.org
Subject: Re: [PATCH v3 1/3] ethdev: rename action modify field data
structure
On 1/15/2024 9:13 AM, Suanming Mou wrote:
> Current rte_flow_action_modify_data struct describes the pkt field
> perfectly and is used only in action.
>
> It is planned to be used for item as well. This commit renames it to
> "rte_flow_field_data" making it compatible to be used by item.
>
ack to rename struct to use in pattern.
> Signed-off-by: Suanming Mou
> Acked-by: Ori Kam
> Acked-by: Andrew Rybchenko
> ---
> app/test-pmd/cmdline_flow.c| 2 +-
> doc/guides/prog_guide/rte_flow.rst | 2 +-
> doc/guides/rel_notes/release_24_03.rst | 1 +
> drivers/net/mlx5/mlx5_flow.c | 4 ++--
> drivers/net/mlx5/mlx5_flow.h | 6 +++---
> drivers/net/mlx5/mlx5_flow_dv.c| 10 +-
> lib/ethdev/rte_flow.h | 8
> 7 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/app/test-pmd/cmdline_flow.c
> b/app/test-pmd/cmdline_flow.c index ce71818705..3725e955c7 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -740,7 +740,7 @@ enum index {
> #define ITEM_RAW_SIZE \
> (sizeof(struct rte_flow_item_raw) + ITEM_RAW_PATTERN_SIZE)
>
> -/** Maximum size for external pattern in struct
> rte_flow_action_modify_data. */
> +/** Maximum size for external pattern in struct rte_flow_field_data.
> +*/
> #define ACTION_MODIFY_PATTERN_SIZE 32
>
What do you think to update 'ACTION_MODIFY_PATTERN_SIZE' here too,
instead of next patch?
>>>
>>> Agree.
>>>
<...>
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index
> affdc8121b..40f6dcaacd 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -3910,9 +3910,9 @@ enum rte_flow_field_id {
> * @warning
> * @b EXPERIMENTAL: this structure may change without prior notice
> *
> - * Field description for MODIFY_FIELD action.
> + * Field description for packet field.
>
New note is not very helpful, how can we make it more useful?
Does it make sense to keep 'MODIFY_FIELD' and add 'COMPARE ITEM' in
next patch, to clarify the intended usage for the struct, otherwise it is
too
>> generic.
>>>
>>> OK, sorry, the purpose is to make it generic. So next time if other ITEM or
>> ACTION need that field, it can be used directly.
>>> Otherwise, it feels like it can only be used by 'MODIFY_FIELD' and
>> 'COMPARE_ITEM', what do you think?
>>>
>>
>> I don't have an intention to limit its usage, but to clarify usage for
>> whoever checks
>> the document.
>>
>> "Field description for packet field." doesn't say what exactly it is and
>> cause
>> confusion.
>>
>> Perhaps wording can be changed to say two possible usages are for
>> 'MODIFY_FIELD' and 'COMPARE_ITEM'?
>
> Sounds good, OK, I will update.
>
> BTW, I saw the patch apply failed, seems it is due to Raslan's branch has
> some extra features than your branch.
> So I just want to know is it OK? Or should I still base on your branch? When
> will the branches be synced.
>
Thanks.
Can you please rebase next version on next-net, this way we can benefit
from CI checks?
RE: [PATCH v3 1/3] ethdev: rename action modify field data structure
> -Original Message-
> From: Ferruh Yigit
> Sent: Thursday, February 1, 2024 7:21 PM
> To: Suanming Mou ; Ori Kam ;
> Aman Singh ; Yuying Zhang
> ; Dariusz Sosnowski ; Slava
> Ovsiienko ; Matan Azrad ; NBU-
> Contact-Thomas Monjalon (EXTERNAL) ; Andrew
> Rybchenko
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v3 1/3] ethdev: rename action modify field data structure
>
> On 2/1/2024 11:09 AM, Suanming Mou wrote:
> >
> >
> >> -Original Message-
> >> From: Ferruh Yigit
> >> Sent: Thursday, February 1, 2024 6:56 PM
> >> To: Suanming Mou ; Ori Kam ;
> >> Aman Singh ; Yuying Zhang
> >> ; Dariusz Sosnowski ;
> >> Slava Ovsiienko ; Matan Azrad
> >> ; NBU- Contact-Thomas Monjalon (EXTERNAL)
> >> ; Andrew Rybchenko
> >>
> >> Cc: dev@dpdk.org
> >> Subject: Re: [PATCH v3 1/3] ethdev: rename action modify field data
> >> structure
> >>
> >> On 1/31/2024 2:57 AM, Suanming Mou wrote:
> >>> Hi,
> >>>
> -Original Message-
> From: Ferruh Yigit
> Sent: Wednesday, January 31, 2024 1:19 AM
> To: Suanming Mou ; Ori Kam
> ; Aman Singh ; Yuying
> Zhang ; Dariusz Sosnowski
> ; Slava Ovsiienko ;
> Matan Azrad ; NBU- Contact-Thomas Monjalon
> (EXTERNAL) ; Andrew Rybchenko
>
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v3 1/3] ethdev: rename action modify field data
> structure
>
> On 1/15/2024 9:13 AM, Suanming Mou wrote:
> > Current rte_flow_action_modify_data struct describes the pkt field
> > perfectly and is used only in action.
> >
> > It is planned to be used for item as well. This commit renames it
> > to "rte_flow_field_data" making it compatible to be used by item.
> >
>
> ack to rename struct to use in pattern.
>
> > Signed-off-by: Suanming Mou
> > Acked-by: Ori Kam
> > Acked-by: Andrew Rybchenko
> > ---
> > app/test-pmd/cmdline_flow.c| 2 +-
> > doc/guides/prog_guide/rte_flow.rst | 2 +-
> > doc/guides/rel_notes/release_24_03.rst | 1 +
> > drivers/net/mlx5/mlx5_flow.c | 4 ++--
> > drivers/net/mlx5/mlx5_flow.h | 6 +++---
> > drivers/net/mlx5/mlx5_flow_dv.c| 10 +-
> > lib/ethdev/rte_flow.h | 8
> > 7 files changed, 17 insertions(+), 16 deletions(-)
> >
> > diff --git a/app/test-pmd/cmdline_flow.c
> > b/app/test-pmd/cmdline_flow.c index ce71818705..3725e955c7 100644
> > --- a/app/test-pmd/cmdline_flow.c
> > +++ b/app/test-pmd/cmdline_flow.c
> > @@ -740,7 +740,7 @@ enum index {
> > #define ITEM_RAW_SIZE \
> > (sizeof(struct rte_flow_item_raw) + ITEM_RAW_PATTERN_SIZE)
> >
> > -/** Maximum size for external pattern in struct
> > rte_flow_action_modify_data. */
> > +/** Maximum size for external pattern in struct rte_flow_field_data.
> > +*/
> > #define ACTION_MODIFY_PATTERN_SIZE 32
> >
>
> What do you think to update 'ACTION_MODIFY_PATTERN_SIZE' here too,
> instead of next patch?
> >>>
> >>> Agree.
> >>>
>
> <...>
>
> > diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index
> > affdc8121b..40f6dcaacd 100644
> > --- a/lib/ethdev/rte_flow.h
> > +++ b/lib/ethdev/rte_flow.h
> > @@ -3910,9 +3910,9 @@ enum rte_flow_field_id {
> > * @warning
> > * @b EXPERIMENTAL: this structure may change without prior notice
> > *
> > - * Field description for MODIFY_FIELD action.
> > + * Field description for packet field.
> >
>
> New note is not very helpful, how can we make it more useful?
>
> Does it make sense to keep 'MODIFY_FIELD' and add 'COMPARE ITEM' in
> next patch, to clarify the intended usage for the struct, otherwise
> it is too
> >> generic.
> >>>
> >>> OK, sorry, the purpose is to make it generic. So next time if other
> >>> ITEM or
> >> ACTION need that field, it can be used directly.
> >>> Otherwise, it feels like it can only be used by 'MODIFY_FIELD' and
> >> 'COMPARE_ITEM', what do you think?
> >>>
> >>
> >> I don't have an intention to limit its usage, but to clarify usage
> >> for whoever checks the document.
> >>
> >> "Field description for packet field." doesn't say what exactly it is
> >> and cause confusion.
> >>
> >> Perhaps wording can be changed to say two possible usages are for
> >> 'MODIFY_FIELD' and 'COMPARE_ITEM'?
> >
> > Sounds good, OK, I will update.
> >
> > BTW, I saw the patch apply failed, seems it is due to Raslan's branch has
> > some
> extra features than your branch.
> > So I just want to know is it OK? Or should I still base on your branch?
> > When will
> the branches be synced.
> >
>
> Thanks.
>
> Can you please rebase next version on next-net, this way we can benefit from
> CI
> checks?
OK, got it.
Re: [PATCH] telemetry: avoid truncation of strlcpy return before check
On Tue, Aug 8, 2023 at 8:35 PM Bruce Richardson
wrote:
>
> On Tue, Aug 08, 2023 at 10:59:37AM -0700, Tyler Retzlaff wrote:
> > On Tue, Aug 08, 2023 at 10:24:41AM +0800, lihuisong (C) wrote:
> > >
> > > 在 2023/8/3 5:21, Tyler Retzlaff 写道:
> > > >strlcpy returns type size_t when directly assigning to
> > > >struct rte_tel_data data_len field it may be truncated leading to
> > > >compromised length check that follows
> > > >
> > > >Since the limit in the check is < UINT_MAX the value returned is
> > > >safe to be cast to unsigned int (which may be narrower than size_t)
> > > >but only after being checked against RTE_TEL_MAX_SINGLE_STRING_LEN
> > > >
> > > >Signed-off-by: Tyler Retzlaff
> > > >---
> > > > lib/telemetry/telemetry_data.c | 5 +++--
> > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > >diff --git a/lib/telemetry/telemetry_data.c
> > > >b/lib/telemetry/telemetry_data.c
> > > >index 3b1a240..52307cb 100644
> > > >--- a/lib/telemetry/telemetry_data.c
> > > >+++ b/lib/telemetry/telemetry_data.c
> > > >@@ -41,12 +41,13 @@
> > > > int
> > > > rte_tel_data_string(struct rte_tel_data *d, const char *str)
> > > > {
> > > >+ const size_t len = strlcpy(d->data.str, str, sizeof(d->data.str));
> > > sizeof(d->data.str) is equal to RTE_TEL_MAX_SINGLE_STRING_LEN(8192).
> > > So It seems that this truncation probably will not happen.
> >
> > agreed, regardless the data type choices permit a size that exceeds the
> > range of the narrower type and the assignment results in a warning being
> > generated on some targets. that's why the truncating cast is safe to
> > add.
> >
> > none of this would be necessary if data_len had been appropriately typed
> > as size_t. Bruce should we be changing the type instead since we are in
> > 23.11 merge window...?
> >
> I'm fine either way, to be honest.
Can we conclude?
struct rte_tel_data seems internal (at least opaque from an
application pov), so I suppose the option of changing data_len to
size_t is still on the table.
And we are missing a Fixes: tag too.
Thanks.
--
David Marchand
Re: [PATCH] telemetry: correct json empty dictionaries
On Fri, Jan 19, 2024 at 8:48 AM Jonathan Erb wrote:
>
> Fix to allow telemetry to handle empty dictionaries correctly.
>
> This patch resolves an issue where empty dictionaries are reported
> by telemetry as '[]' rather than '{}'. Initializing the output
> buffer based on the container type resolves the issue.
>
> Signed-off-by: Jonathan Erb
Thanks for the fix.
Could you point at the change that introduced this issue?
I will add the Fixes: tag when applying.
--
David Marchand
Re: [PATCH] cfgfile: increase value length
On 2/1/2024 4:02 PM, David Marchand wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
On Wed, Dec 6, 2023 at 12:31 PM Vipin Varghese wrote:
The default value for CFG_VALUE_LEN is set to 256 characters.
This limits the parsing for longer strings in configuration file.
Setting the default to 2048 characters increases the value array
size in `struct rte_cfgfile_entry`.
Files using cfgfile library are
1. drivers/net/mvpp2/
2. app/test-dma-perf/
3. app/test/
4. examples/qos_sched/
The structure `rte_cfgfile_entry` is not included in DPDK libraries.
Modifying from 256 to 2048 allows `app/test-dma-perf/main.c` helps to
parse longer string as shared in https://bugs.dpdk.org/show_bug.cgi?id=1333
Signed-off-by: Vipin Varghese
Suggested-by: Ferruh Yigit
---
lib/cfgfile/rte_cfgfile.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/cfgfile/rte_cfgfile.h b/lib/cfgfile/rte_cfgfile.h
index 232c65c77b..401353c44e 100644
--- a/lib/cfgfile/rte_cfgfile.h
+++ b/lib/cfgfile/rte_cfgfile.h
@@ -24,7 +24,7 @@ extern "C" {
#endif
#ifndef CFG_VALUE_LEN
-#define CFG_VALUE_LEN 256
+#define CFG_VALUE_LEN 2048
#endif
/** Configuration file */
Last time I looked at this code, I had the impression such a change
would break the ABI.
Thanks David, Internally & 7 Dec 2023 based on the covnersation email
from Bruce & Cristian; the new approach DPDK community should be taking
is not to use comma seperated DMA instance.
Instead make DMA instances like `dma-1:, dma-2:, dma-3 ... etc`.
I see that the discussion stopped at a suggestion to change some parsing logic.
For now, I marked this patch as Changes requested.
I will make this deffer-ed or close the same.
Thanks.
--
David Marchand
[PATCH v5 0/3] ethdev: add RTE_FLOW_ITEM_TYPE_COMPARE
The new item type is added for the case user wants to match traffic based on packet field compare result with other fields or immediate value. e.g. take advantage the compare item user will be able to accumulate a IPv4/TCP packet's TCP data_offset and IPv4 IHL field to a tag register, then compare the tag register with IPv4 header total length to understand the packet has payload or not. The supported operations can be as below: - RTE_FLOW_ITEM_COMPARE_EQ (equal) - RTE_FLOW_ITEM_COMPARE_NE (not equal) - RTE_FLOW_ITEM_COMPARE_LT (less than) - RTE_FLOW_ITEM_COMPARE_LE (less than or equal) - RTE_FLOW_ITEM_COMPARE_GT (great than) - RTE_FLOW_ITEM_COMPARE_GE (great than or equal) V5: - rebase on top of next-net - add sample detail for rte_flow_field. V4: - rebase on top of the latest version. - move ACTION_MODIFY_PATTERN_SIZE and modify_field_ids rename to first patch. - add comparison flow create sample in testpmd_funcs.rst. V3: - fix code style missing empty line in rte_flow.rst. - fix missing the ABI change release notes. V2: - Since modify field data struct is experiment, rename modify field data directly instead of adding new flow field struct. Suanming Mou (3): ethdev: rename action modify field data structure ethdev: add compare item net/mlx5: add compare item support app/test-pmd/cmdline_flow.c | 416 +++- doc/guides/nics/features/default.ini| 1 + doc/guides/nics/features/mlx5.ini | 1 + doc/guides/nics/mlx5.rst| 7 + doc/guides/prog_guide/rte_flow.rst | 9 +- doc/guides/rel_notes/release_24_03.rst | 8 + doc/guides/testpmd_app_ug/testpmd_funcs.rst | 24 ++ drivers/net/mlx5/mlx5_flow.c| 4 +- drivers/net/mlx5/mlx5_flow.h| 9 +- drivers/net/mlx5/mlx5_flow_dv.c | 10 +- drivers/net/mlx5/mlx5_flow_hw.c | 73 lib/ethdev/rte_flow.c | 1 + lib/ethdev/rte_flow.h | 332 +--- 13 files changed, 726 insertions(+), 169 deletions(-) -- 2.34.1
[PATCH v5 1/3] ethdev: rename action modify field data structure
Current rte_flow_action_modify_data struct describes the pkt
field perfectly and is used only in action.
It is planned to be used for item as well. This commit renames
it to "rte_flow_field_data" making it compatible to be used by item.
Signed-off-by: Suanming Mou
Acked-by: Ori Kam
Acked-by: Andrew Rybchenko
---
app/test-pmd/cmdline_flow.c| 22 +++---
doc/guides/prog_guide/rte_flow.rst | 2 +-
doc/guides/rel_notes/release_24_03.rst | 1 +
drivers/net/mlx5/mlx5_flow.c | 4 ++--
drivers/net/mlx5/mlx5_flow.h | 6 +++---
drivers/net/mlx5/mlx5_flow_dv.c| 10 +-
lib/ethdev/rte_flow.h | 12
7 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 359c187b3c..972c6ae490 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -742,13 +742,13 @@ enum index {
#define ITEM_RAW_SIZE \
(sizeof(struct rte_flow_item_raw) + ITEM_RAW_PATTERN_SIZE)
-/** Maximum size for external pattern in struct rte_flow_action_modify_data. */
-#define ACTION_MODIFY_PATTERN_SIZE 32
+/** Maximum size for external pattern in struct rte_flow_field_data. */
+#define FLOW_FIELD_PATTERN_SIZE 32
/** Storage size for struct rte_flow_action_modify_field including pattern. */
#define ACTION_MODIFY_SIZE \
(sizeof(struct rte_flow_action_modify_field) + \
- ACTION_MODIFY_PATTERN_SIZE)
+ FLOW_FIELD_PATTERN_SIZE)
/** Maximum number of queue indices in struct rte_flow_action_rss. */
#define ACTION_RSS_QUEUE_NUM 128
@@ -942,7 +942,7 @@ static const char *const modify_field_ops[] = {
"set", "add", "sub", NULL
};
-static const char *const modify_field_ids[] = {
+static const char *const flow_field_ids[] = {
"start", "mac_dst", "mac_src",
"vlan_type", "vlan_id", "mac_type",
"ipv4_dscp", "ipv4_ttl", "ipv4_src", "ipv4_dst",
@@ -6986,7 +6986,7 @@ static const struct token token_list[] = {
ARGS_ENTRY_ARB(0, 0),
ARGS_ENTRY_ARB
(sizeof(struct rte_flow_action_modify_field),
-ACTION_MODIFY_PATTERN_SIZE)),
+FLOW_FIELD_PATTERN_SIZE)),
.call = parse_vc_conf,
},
[ACTION_MODIFY_FIELD_WIDTH] = {
@@ -9798,10 +9798,10 @@ parse_vc_modify_field_id(struct context *ctx, const
struct token *token,
if (ctx->curr != ACTION_MODIFY_FIELD_DST_TYPE_VALUE &&
ctx->curr != ACTION_MODIFY_FIELD_SRC_TYPE_VALUE)
return -1;
- for (i = 0; modify_field_ids[i]; ++i)
- if (!strcmp_partial(modify_field_ids[i], str, len))
+ for (i = 0; flow_field_ids[i]; ++i)
+ if (!strcmp_partial(flow_field_ids[i], str, len))
break;
- if (!modify_field_ids[i])
+ if (!flow_field_ids[i])
return -1;
if (!ctx->object)
return len;
@@ -12028,10 +12028,10 @@ comp_set_modify_field_id(struct context *ctx, const
struct token *token,
RTE_SET_USED(token);
if (!buf)
- return RTE_DIM(modify_field_ids);
- if (ent >= RTE_DIM(modify_field_ids) - 1)
+ return RTE_DIM(flow_field_ids);
+ if (ent >= RTE_DIM(flow_field_ids) - 1)
return -1;
- name = modify_field_ids[ent];
+ name = flow_field_ids[ent];
if (ctx->curr == ACTION_MODIFY_FIELD_SRC_TYPE ||
(strcmp(name, "pointer") && strcmp(name, "value")))
return strlcpy(buf, name, size);
diff --git a/doc/guides/prog_guide/rte_flow.rst
b/doc/guides/prog_guide/rte_flow.rst
index 900fdaefb6..f936a9ba19 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -3185,7 +3185,7 @@ destination offset as ``48``, and provide immediate value
``0x85XX``.
| ``width`` | number of bits to use |
+---+-+
-.. _table_rte_flow_action_modify_data:
+.. _table_rte_flow_field_data:
.. table:: destination/source field definition
diff --git a/doc/guides/rel_notes/release_24_03.rst
b/doc/guides/rel_notes/release_24_03.rst
index 84d3144215..efeda6ea97 100644
--- a/doc/guides/rel_notes/release_24_03.rst
+++ b/doc/guides/rel_notes/release_24_03.rst
@@ -124,6 +124,7 @@ ABI Changes
* No ABI change that would break compatibility with 23.11.
+* ethdev: Rename the experimental ``struct rte_flow_action_modify_data`` to be
``struct rte_flow_field_data``
Known Issues
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 85e8c77c81..5788a7fb57 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -2493,7 +2493,7 @@ mlx5_validate_action_ct(struct rte_eth_dev *dev,
* Validate the level value for modify field action.
*
* @param[in]
[PATCH v5 2/3] ethdev: add compare item
The new item type is added for the case user wants to match traffic
based on packet field compare result with other fields or immediate
value.
e.g. take advantage the compare item user will be able to accumulate
a IPv4/TCP packet's TCP data_offset and IPv4 IHL field to a tag
register, then compare the tag register with IPv4 header total length
to understand the packet has payload or not.
The supported operations can be as below:
- RTE_FLOW_ITEM_COMPARE_EQ (equal)
- RTE_FLOW_ITEM_COMPARE_NE (not equal)
- RTE_FLOW_ITEM_COMPARE_LT (less than)
- RTE_FLOW_ITEM_COMPARE_LE (less than or equal)
- RTE_FLOW_ITEM_COMPARE_GT (great than)
- RTE_FLOW_ITEM_COMPARE_GE (great than or equal)
A sample for create the comparison flow:
flow pattern_template 0 create ingress pattern_template_id 1 template \
compare op mask le a_type mask tag a_tag_index mask 1 b_type \
mask tag b_tag_index mask 2 width mask 0x / end
flow actions_template 0 create ingress actions_template_id 1 template \
count / drop / end mask count / drop / end
flow template_table 0 create table_id 1 group 2 priority 1 ingress \
rules_number 1 pattern_template 1 actions_template 1
flow queue 0 create 0 template_table 1 pattern_template 0 \
actions_template 0 postpone no pattern compare op is le \
a_type is tag a_tag_index is 1 b_type is tag b_tag_index is 2 \
width is 32 / end actions count / drop / end
Signed-off-by: Suanming Mou
Acked-by: Ori Kam
Acked-by: Andrew Rybchenko
---
app/test-pmd/cmdline_flow.c | 394
doc/guides/nics/features/default.ini| 1 +
doc/guides/prog_guide/rte_flow.rst | 7 +
doc/guides/rel_notes/release_24_03.rst | 5 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 24 ++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 332 +
7 files changed, 615 insertions(+), 149 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 972c6ae490..69b14c6eb1 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -545,6 +545,28 @@ enum index {
ITEM_PTYPE,
ITEM_PTYPE_VALUE,
ITEM_NSH,
+ ITEM_COMPARE,
+ ITEM_COMPARE_OP,
+ ITEM_COMPARE_OP_VALUE,
+ ITEM_COMPARE_FIELD_A_TYPE,
+ ITEM_COMPARE_FIELD_A_TYPE_VALUE,
+ ITEM_COMPARE_FIELD_A_LEVEL,
+ ITEM_COMPARE_FIELD_A_LEVEL_VALUE,
+ ITEM_COMPARE_FIELD_A_TAG_INDEX,
+ ITEM_COMPARE_FIELD_A_TYPE_ID,
+ ITEM_COMPARE_FIELD_A_CLASS_ID,
+ ITEM_COMPARE_FIELD_A_OFFSET,
+ ITEM_COMPARE_FIELD_B_TYPE,
+ ITEM_COMPARE_FIELD_B_TYPE_VALUE,
+ ITEM_COMPARE_FIELD_B_LEVEL,
+ ITEM_COMPARE_FIELD_B_LEVEL_VALUE,
+ ITEM_COMPARE_FIELD_B_TAG_INDEX,
+ ITEM_COMPARE_FIELD_B_TYPE_ID,
+ ITEM_COMPARE_FIELD_B_CLASS_ID,
+ ITEM_COMPARE_FIELD_B_OFFSET,
+ ITEM_COMPARE_FIELD_B_VALUE,
+ ITEM_COMPARE_FIELD_B_POINTER,
+ ITEM_COMPARE_FIELD_WIDTH,
/* Validate/create actions. */
ACTIONS,
@@ -742,6 +764,10 @@ enum index {
#define ITEM_RAW_SIZE \
(sizeof(struct rte_flow_item_raw) + ITEM_RAW_PATTERN_SIZE)
+static const char *const compare_ops[] = {
+ "eq", "ne", "lt", "le", "gt", "ge", NULL
+};
+
/** Maximum size for external pattern in struct rte_flow_field_data. */
#define FLOW_FIELD_PATTERN_SIZE 32
@@ -1594,6 +1620,7 @@ static const enum index next_item[] = {
ITEM_IB_BTH,
ITEM_PTYPE,
ITEM_NSH,
+ ITEM_COMPARE,
END_SET,
ZERO,
};
@@ -2131,6 +2158,38 @@ static const enum index item_nsh[] = {
ZERO,
};
+static const enum index item_compare_field[] = {
+ ITEM_COMPARE_OP,
+ ITEM_COMPARE_FIELD_A_TYPE,
+ ITEM_COMPARE_FIELD_B_TYPE,
+ ITEM_NEXT,
+ ZERO,
+};
+
+static const enum index compare_field_a[] = {
+ ITEM_COMPARE_FIELD_A_TYPE,
+ ITEM_COMPARE_FIELD_A_LEVEL,
+ ITEM_COMPARE_FIELD_A_TAG_INDEX,
+ ITEM_COMPARE_FIELD_A_TYPE_ID,
+ ITEM_COMPARE_FIELD_A_CLASS_ID,
+ ITEM_COMPARE_FIELD_A_OFFSET,
+ ITEM_COMPARE_FIELD_B_TYPE,
+ ZERO,
+};
+
+static const enum index compare_field_b[] = {
+ ITEM_COMPARE_FIELD_B_TYPE,
+ ITEM_COMPARE_FIELD_B_LEVEL,
+ ITEM_COMPARE_FIELD_B_TAG_INDEX,
+ ITEM_COMPARE_FIELD_B_TYPE_ID,
+ ITEM_COMPARE_FIELD_B_CLASS_ID,
+ ITEM_COMPARE_FIELD_B_OFFSET,
+ ITEM_COMPARE_FIELD_B_VALUE,
+ ITEM_COMPARE_FIELD_B_POINTER,
+ ITEM_COMPARE_FIELD_WIDTH,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -2873,6 +2932,24 @@ comp_quota_update_name(struct context *ctx, const struct
token *token,
static int
comp_qu_mode_name(struct context *ctx, const struct token *token,
unsigned int ent, char *buf, unsigned int size);
+static int
+comp_set_compare_field_id(stru
[PATCH v5 3/3] net/mlx5: add compare item support
The compare item allows adding flow match with comparison
result. This commit adds compare item support to the PMD
code.
Due to HW limitation:
- Only HWS supported.
- Only 32-bit comparison is supported.
- Only single compare flow is supported in the flow table.
- Only match with compare result between packet fields is
supported.
Signed-off-by: Suanming Mou
Acked-by: Ori Kam
---
doc/guides/nics/features/mlx5.ini | 1 +
doc/guides/nics/mlx5.rst | 7 +++
doc/guides/rel_notes/release_24_03.rst | 2 +
drivers/net/mlx5/mlx5_flow.h | 3 ++
drivers/net/mlx5/mlx5_flow_hw.c| 73 ++
5 files changed, 86 insertions(+)
diff --git a/doc/guides/nics/features/mlx5.ini
b/doc/guides/nics/features/mlx5.ini
index 0739fe9d63..00e9348fc6 100644
--- a/doc/guides/nics/features/mlx5.ini
+++ b/doc/guides/nics/features/mlx5.ini
@@ -56,6 +56,7 @@ Usage doc= Y
[rte_flow items]
aggr_affinity= Y
+compare = Y
conntrack= Y
ecpri= Y
esp = Y
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 6b52fb93c5..18b40bc22d 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -778,6 +778,13 @@ Limitations
The flow engine of a process cannot move from active to standby mode
if preceding active application rules are still present and vice versa.
+- Match with compare result item (``RTE_FLOW_ITEM_TYPE_COMPARE``):
+
+ - Only supported in HW steering(``dv_flow_en`` = 2) mode.
+ - Only single flow is supported to the flow table.
+ - Only 32-bit comparison is supported.
+ - Only match with compare result between packet fields is supported.
+
Statistics
--
diff --git a/doc/guides/rel_notes/release_24_03.rst
b/doc/guides/rel_notes/release_24_03.rst
index ffceab59e4..91b2cafb00 100644
--- a/doc/guides/rel_notes/release_24_03.rst
+++ b/doc/guides/rel_notes/release_24_03.rst
@@ -80,6 +80,8 @@ New Features
* Added support for Atomic Rules' TK242 packet-capture family of devices
with PCI IDs: ``0x1024, 0x1025, 0x1026``.
+ * Added support for comparing result between packet fields or value.
+
Removed Items
-
diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
index ecfb04ead2..f0a11949e6 100644
--- a/drivers/net/mlx5/mlx5_flow.h
+++ b/drivers/net/mlx5/mlx5_flow.h
@@ -277,6 +277,9 @@ enum mlx5_feature_name {
/* NSH ITEM */
#define MLX5_FLOW_ITEM_NSH (1ull << 53)
+/* COMPARE ITEM */
+#define MLX5_FLOW_ITEM_COMPARE (1ull << 54)
+
/* Outer Masks. */
#define MLX5_FLOW_LAYER_OUTER_L3 \
(MLX5_FLOW_LAYER_OUTER_L3_IPV4 | MLX5_FLOW_LAYER_OUTER_L3_IPV6)
diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index da873ae2e2..f21c22131c 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -426,6 +426,9 @@ flow_hw_matching_item_flags_get(const struct rte_flow_item
items[])
case RTE_FLOW_ITEM_TYPE_GTP:
last_item = MLX5_FLOW_LAYER_GTP;
break;
+ case RTE_FLOW_ITEM_TYPE_COMPARE:
+ last_item = MLX5_FLOW_ITEM_COMPARE;
+ break;
default:
break;
}
@@ -4386,6 +4389,8 @@ flow_hw_table_create(struct rte_eth_dev *dev,
rte_errno = EINVAL;
goto it_error;
}
+ if (item_templates[i]->item_flags & MLX5_FLOW_ITEM_COMPARE)
+ matcher_attr.mode = MLX5DR_MATCHER_RESOURCE_MODE_HTABLE;
ret = __atomic_fetch_add(&item_templates[i]->refcnt, 1,
__ATOMIC_RELAXED) + 1;
if (ret <= 1) {
@@ -6634,6 +6639,66 @@ flow_hw_prepend_item(const struct rte_flow_item *items,
return copied_items;
}
+static inline bool
+flow_hw_item_compare_field_supported(enum rte_flow_field_id field)
+{
+ switch (field) {
+ case RTE_FLOW_FIELD_TAG:
+ case RTE_FLOW_FIELD_META:
+ case RTE_FLOW_FIELD_VALUE:
+ return true;
+ default:
+ break;
+ }
+ return false;
+}
+
+static int
+flow_hw_validate_item_compare(const struct rte_flow_item *item,
+ struct rte_flow_error *error)
+{
+ const struct rte_flow_item_compare *comp_m = item->mask;
+ const struct rte_flow_item_compare *comp_v = item->spec;
+
+ if (unlikely(!comp_m))
+ return rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+ NULL,
+ "compare item mask is missing");
+ if (comp_m->width != UINT32_MAX)
+ return rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+
[PATCH v3 00/23] net/cnxk: support for port representors
Introducing port representor support to CNXK drivers by adding virtual ethernet ports providing a logical representation in DPDK for physical function(PF) or SR-IOV virtual function (VF) devices for control and monitoring. These port representor ethdev instances can be spawned on an as needed basis through configuration parameters passed to the driver of the underlying base device using devargs ``-a ,representor=pf*vf*`` In case of exception path (i.e. until the flow definition is offloaded to the hardware), packets transmitted by the VFs shall be received by these representor port, while packets transmitted by representor ports shall be received by respective VFs. On receiving the VF traffic via these representor ports, applications holding these representor ports can decide to offload the traffic flow into the HW. Henceforth the matching traffic shall be directly steered to the respective VFs without being received by the application. Current virtual representor port PMD supports following operations: - Get represented port statistics - Flow operations - create, validate, destroy, query, flush, dump Changes since V2: * Moved devargs parsing logic to common code and sent as separate series * Documentation updated * Addressed comments from V2 Changes since V1: * Updated communication layer between representor and represented port. * Added support for native represented ports * Port representor and represented port item and action support * Build failure fixes Harman Kalra (21): common/cnxk: add support for representors net/cnxk: implementing eswitch device net/cnxk: eswitch HW resource configuration net/cnxk: eswitch devargs parsing net/cnxk: probing representor ports common/cnxk: common NPC changes for eswitch common/cnxk: interface to update VLAN TPID net/cnxk: eswitch flow configurations net/cnxk: eswitch fastpath routines net/cnxk: add representor control plane common/cnxk: representee notification callback net/cnxk: handling representee notification net/cnxk: representor ethdev ops common/cnxk: get representees ethernet stats net/cnxk: ethernet statistic for representor common/cnxk: base support for eswitch VF net/cnxk: eswitch VF as ethernet device net/cnxk: add representor port pattern and action net/cnxk: generalise flow operation APIs net/cnxk: flow create on representor ports net/cnxk: other flow operations Kiran Kumar K (2): common/cnxk: support port representor and represented port net/cnxk: add represented port pattern and action MAINTAINERS | 1 + doc/guides/nics/cnxk.rst| 41 ++ doc/guides/nics/features/cnxk.ini | 5 + doc/guides/nics/features/cnxk_vec.ini | 6 + doc/guides/nics/features/cnxk_vf.ini| 6 + drivers/common/cnxk/meson.build | 1 + drivers/common/cnxk/roc_api.h | 3 + drivers/common/cnxk/roc_constants.h | 2 + drivers/common/cnxk/roc_dev.c | 25 + drivers/common/cnxk/roc_dev_priv.h | 3 + drivers/common/cnxk/roc_eswitch.c | 389 +++ drivers/common/cnxk/roc_eswitch.h | 34 + drivers/common/cnxk/roc_mbox.c | 2 + drivers/common/cnxk/roc_mbox.h | 82 ++- drivers/common/cnxk/roc_nix.c | 46 +- drivers/common/cnxk/roc_nix.h | 4 + drivers/common/cnxk/roc_nix_priv.h | 12 +- drivers/common/cnxk/roc_nix_vlan.c | 23 +- drivers/common/cnxk/roc_npc.c | 89 ++- drivers/common/cnxk/roc_npc.h | 18 +- drivers/common/cnxk/roc_npc_mcam.c | 64 +- drivers/common/cnxk/roc_npc_parse.c | 28 +- drivers/common/cnxk/roc_npc_priv.h | 5 +- drivers/common/cnxk/roc_platform.c | 2 + drivers/common/cnxk/roc_platform.h | 4 + drivers/common/cnxk/version.map | 14 + drivers/net/cnxk/cn10k_ethdev.c | 1 + drivers/net/cnxk/cnxk_eswitch.c | 807 +++ drivers/net/cnxk/cnxk_eswitch.h | 213 ++ drivers/net/cnxk/cnxk_eswitch_devargs.c | 125 drivers/net/cnxk/cnxk_eswitch_flow.c| 454 + drivers/net/cnxk/cnxk_eswitch_rxtx.c| 211 ++ drivers/net/cnxk/cnxk_ethdev.c | 41 +- drivers/net/cnxk/cnxk_ethdev.h | 3 + drivers/net/cnxk/cnxk_ethdev_ops.c | 4 + drivers/net/cnxk/cnxk_flow.c| 546 drivers/net/cnxk/cnxk_flow.h| 27 +- drivers/net/cnxk/cnxk_link.c| 3 +- drivers/net/cnxk/cnxk_rep.c | 555 drivers/net/cnxk/cnxk_rep.h | 141 drivers/net/cnxk/cnxk_rep_flow.c| 815 +++ drivers/net/cnxk/cnxk_rep_msg.c | 827 drivers/net/cnxk/cnxk_rep_msg.h | 169 + drivers/net/cnxk/cnxk_rep_ops.c | 715 drivers/net/cnxk/meson.build| 8 + 45 files changed, 6371 insertions(+), 203 deletions(-) create mode 100644 dr
[PATCH v3 01/23] common/cnxk: add support for representors
Introducing a new Mailbox for registering base device behind
all representors and also registering debug log type for representors
and base device driver.
Signed-off-by: Harman Kalra
---
doc/guides/nics/cnxk.rst| 4
drivers/common/cnxk/roc_constants.h | 1 +
drivers/common/cnxk/roc_mbox.h | 8
drivers/common/cnxk/roc_nix.c | 31 +
drivers/common/cnxk/roc_nix.h | 3 +++
drivers/common/cnxk/roc_platform.c | 2 ++
drivers/common/cnxk/roc_platform.h | 4
drivers/common/cnxk/version.map | 3 +++
8 files changed, 56 insertions(+)
diff --git a/doc/guides/nics/cnxk.rst b/doc/guides/nics/cnxk.rst
index 9ec52e380f..58cb8e2283 100644
--- a/doc/guides/nics/cnxk.rst
+++ b/doc/guides/nics/cnxk.rst
@@ -627,3 +627,7 @@ Debugging Options
+---++---+
| 2 | NPC| --log-level='pmd\.net.cnxk\.flow,8' |
+---++---+
+ | 3 | REP| --log-level='pmd\.net.cnxk\.rep,8'|
+ +---++---+
+ | 4 | ESW| --log-level='pmd\.net.cnxk\.esw,8'|
+ +---++---+
diff --git a/drivers/common/cnxk/roc_constants.h
b/drivers/common/cnxk/roc_constants.h
index 291b6a4bc9..cb4edbea58 100644
--- a/drivers/common/cnxk/roc_constants.h
+++ b/drivers/common/cnxk/roc_constants.h
@@ -43,6 +43,7 @@
#define PCI_DEVID_CNXK_RVU_NIX_INL_VF 0xA0F1
#define PCI_DEVID_CNXK_RVU_REE_PF 0xA0f4
#define PCI_DEVID_CNXK_RVU_REE_VF 0xA0f5
+#define PCI_DEVID_CNXK_RVU_ESWITCH_PF 0xA0E0
#define PCI_DEVID_CN9K_CGX 0xA059
#define PCI_DEVID_CN10K_RPM 0xA060
diff --git a/drivers/common/cnxk/roc_mbox.h b/drivers/common/cnxk/roc_mbox.h
index 3257a370bc..b7e2f43d45 100644
--- a/drivers/common/cnxk/roc_mbox.h
+++ b/drivers/common/cnxk/roc_mbox.h
@@ -68,6 +68,7 @@ struct mbox_msghdr {
M(NDC_SYNC_OP, 0x009, ndc_sync_op, ndc_sync_op, msg_rsp) \
M(LMTST_TBL_SETUP, 0x00a, lmtst_tbl_setup, lmtst_tbl_setup_req,\
msg_rsp) \
+ M(GET_REP_CNT, 0x00d, get_rep_cnt, msg_req, get_rep_cnt_rsp) \
/* CGX mbox IDs (range 0x200 - 0x3FF) */ \
M(CGX_START_RXTX, 0x200, cgx_start_rxtx, msg_req, msg_rsp) \
M(CGX_STOP_RXTX, 0x201, cgx_stop_rxtx, msg_req, msg_rsp) \
@@ -546,6 +547,13 @@ struct lmtst_tbl_setup_req {
uint64_t __io rsvd[2]; /* Future use */
};
+#define MAX_PFVF_REP 64
+struct get_rep_cnt_rsp {
+ struct mbox_msghdr hdr;
+ uint16_t __io rep_cnt;
+ uint16_t __io rep_pfvf_map[MAX_PFVF_REP];
+};
+
/* CGX mbox message formats */
/* CGX mailbox error codes
* Range 1101 - 1200.
diff --git a/drivers/common/cnxk/roc_nix.c b/drivers/common/cnxk/roc_nix.c
index f64933a1d9..7e327a7e6e 100644
--- a/drivers/common/cnxk/roc_nix.c
+++ b/drivers/common/cnxk/roc_nix.c
@@ -531,3 +531,34 @@ roc_nix_dev_fini(struct roc_nix *roc_nix)
rc |= dev_fini(&nix->dev, nix->pci_dev);
return rc;
}
+
+int
+roc_nix_max_rep_count(struct roc_nix *roc_nix)
+{
+ struct nix *nix = roc_nix_to_nix_priv(roc_nix);
+ struct dev *dev = &nix->dev;
+ struct mbox *mbox = mbox_get(dev->mbox);
+ struct get_rep_cnt_rsp *rsp;
+ struct msg_req *req;
+ int rc, i;
+
+ req = mbox_alloc_msg_get_rep_cnt(mbox);
+ if (!req) {
+ rc = -ENOSPC;
+ goto exit;
+ }
+
+ req->hdr.pcifunc = roc_nix_get_pf_func(roc_nix);
+
+ rc = mbox_process_msg(mbox, (void *)&rsp);
+ if (rc)
+ goto exit;
+
+ roc_nix->rep_cnt = rsp->rep_cnt;
+ for (i = 0; i < rsp->rep_cnt; i++)
+ roc_nix->rep_pfvf_map[i] = rsp->rep_pfvf_map[i];
+
+exit:
+ mbox_put(mbox);
+ return rc;
+}
diff --git a/drivers/common/cnxk/roc_nix.h b/drivers/common/cnxk/roc_nix.h
index 84e6fc3df5..b369335fc4 100644
--- a/drivers/common/cnxk/roc_nix.h
+++ b/drivers/common/cnxk/roc_nix.h
@@ -483,6 +483,8 @@ struct roc_nix {
uint32_t buf_sz;
uint64_t meta_aura_handle;
uintptr_t meta_mempool;
+ uint16_t rep_cnt;
+ uint16_t rep_pfvf_map[MAX_PFVF_REP];
TAILQ_ENTRY(roc_nix) next;
#define ROC_NIX_MEM_SZ (6 * 1070)
@@ -1013,4 +1015,5 @@ int __roc_api roc_nix_mcast_list_setup(struct mbox *mbox,
uint8_t intf, int nb_e
uint16_t *pf_funcs, uint16_t *channels,
uint32_t *rqs,
uint32_t *grp_index, uint32_t
*start_index);
int __roc_api roc_nix_mcast_list_free(struct mbox *mbox, uint32_t
mcast_grp_index);
+int __roc_api roc_nix_max_rep_count(struct roc_nix *roc_nix);
[PATCH v3 02/23] net/cnxk: implementing eswitch device
Eswitch device is a parent or base device behind all the representors,
acting as transport layer between representors and representees
Signed-off-by: Harman Kalra
---
drivers/net/cnxk/cnxk_eswitch.c | 378
drivers/net/cnxk/cnxk_eswitch.h | 103 +
drivers/net/cnxk/meson.build| 1 +
3 files changed, 482 insertions(+)
create mode 100644 drivers/net/cnxk/cnxk_eswitch.c
create mode 100644 drivers/net/cnxk/cnxk_eswitch.h
diff --git a/drivers/net/cnxk/cnxk_eswitch.c b/drivers/net/cnxk/cnxk_eswitch.c
new file mode 100644
index 00..c4ea3063ae
--- /dev/null
+++ b/drivers/net/cnxk/cnxk_eswitch.c
@@ -0,0 +1,378 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2024 Marvell.
+ */
+
+#include
+
+#define CNXK_NIX_DEF_SQ_COUNT 512
+
+static int
+cnxk_eswitch_dev_remove(struct rte_pci_device *pci_dev)
+{
+ struct cnxk_eswitch_dev *eswitch_dev;
+ int rc = 0;
+
+ if (rte_eal_process_type() != RTE_PROC_PRIMARY)
+ return 0;
+
+ eswitch_dev = cnxk_eswitch_pmd_priv();
+ if (!eswitch_dev) {
+ rc = -EINVAL;
+ goto exit;
+ }
+
+ rte_free(eswitch_dev);
+exit:
+ return rc;
+}
+
+int
+cnxk_eswitch_nix_rsrc_start(struct cnxk_eswitch_dev *eswitch_dev)
+{
+ int rc;
+
+ /* Enable Rx in NPC */
+ rc = roc_nix_npc_rx_ena_dis(&eswitch_dev->nix, true);
+ if (rc) {
+ plt_err("Failed to enable NPC rx %d", rc);
+ goto done;
+ }
+
+ rc = roc_npc_mcam_enable_all_entries(&eswitch_dev->npc, 1);
+ if (rc) {
+ plt_err("Failed to enable NPC entries %d", rc);
+ goto done;
+ }
+
+done:
+ return 0;
+}
+
+int
+cnxk_eswitch_txq_start(struct cnxk_eswitch_dev *eswitch_dev, uint16_t qid)
+{
+ struct roc_nix_sq *sq = &eswitch_dev->txq[qid].sqs;
+ int rc = -EINVAL;
+
+ if (eswitch_dev->txq[qid].state == CNXK_ESWITCH_QUEUE_STATE_STARTED)
+ return 0;
+
+ if (eswitch_dev->txq[qid].state != CNXK_ESWITCH_QUEUE_STATE_CONFIGURED)
{
+ plt_err("Eswitch txq %d not configured yet", qid);
+ goto done;
+ }
+
+ rc = roc_nix_sq_ena_dis(sq, true);
+ if (rc) {
+ plt_err("Failed to enable sq aura fc, txq=%u, rc=%d", qid, rc);
+ goto done;
+ }
+
+ eswitch_dev->txq[qid].state = CNXK_ESWITCH_QUEUE_STATE_STARTED;
+done:
+ return rc;
+}
+
+int
+cnxk_eswitch_txq_stop(struct cnxk_eswitch_dev *eswitch_dev, uint16_t qid)
+{
+ struct roc_nix_sq *sq = &eswitch_dev->txq[qid].sqs;
+ int rc = -EINVAL;
+
+ if (eswitch_dev->txq[qid].state == CNXK_ESWITCH_QUEUE_STATE_STOPPED ||
+ eswitch_dev->txq[qid].state == CNXK_ESWITCH_QUEUE_STATE_RELEASED)
+ return 0;
+
+ if (eswitch_dev->txq[qid].state != CNXK_ESWITCH_QUEUE_STATE_STARTED) {
+ plt_err("Eswitch txq %d not started", qid);
+ goto done;
+ }
+
+ rc = roc_nix_sq_ena_dis(sq, false);
+ if (rc) {
+ plt_err("Failed to disable sqb aura fc, txq=%u, rc=%d", qid,
rc);
+ goto done;
+ }
+
+ eswitch_dev->txq[qid].state = CNXK_ESWITCH_QUEUE_STATE_STOPPED;
+done:
+ return rc;
+}
+
+int
+cnxk_eswitch_rxq_start(struct cnxk_eswitch_dev *eswitch_dev, uint16_t qid)
+{
+ struct roc_nix_rq *rq = &eswitch_dev->rxq[qid].rqs;
+ int rc = -EINVAL;
+
+ if (eswitch_dev->rxq[qid].state == CNXK_ESWITCH_QUEUE_STATE_STARTED)
+ return 0;
+
+ if (eswitch_dev->rxq[qid].state != CNXK_ESWITCH_QUEUE_STATE_CONFIGURED)
{
+ plt_err("Eswitch rxq %d not configured yet", qid);
+ goto done;
+ }
+
+ rc = roc_nix_rq_ena_dis(rq, true);
+ if (rc) {
+ plt_err("Failed to enable rxq=%u, rc=%d", qid, rc);
+ goto done;
+ }
+
+ eswitch_dev->rxq[qid].state = CNXK_ESWITCH_QUEUE_STATE_STARTED;
+done:
+ return rc;
+}
+
+int
+cnxk_eswitch_rxq_stop(struct cnxk_eswitch_dev *eswitch_dev, uint16_t qid)
+{
+ struct roc_nix_rq *rq = &eswitch_dev->rxq[qid].rqs;
+ int rc = -EINVAL;
+
+ if (eswitch_dev->rxq[qid].state == CNXK_ESWITCH_QUEUE_STATE_STOPPED ||
+ eswitch_dev->rxq[qid].state == CNXK_ESWITCH_QUEUE_STATE_RELEASED)
+ return 0;
+
+ if (eswitch_dev->rxq[qid].state != CNXK_ESWITCH_QUEUE_STATE_STARTED) {
+ plt_err("Eswitch rxq %d not started", qid);
+ goto done;
+ }
+
+ rc = roc_nix_rq_ena_dis(rq, false);
+ if (rc) {
+ plt_err("Failed to disable rxq=%u, rc=%d", qid, rc);
+ goto done;
+ }
+
+ eswitch_dev->rxq[qid].state = CNXK_ESWITCH_QUEUE_STATE_STOPPED;
+done:
+ return rc;
+}
+
+int
+cnxk_eswitch_rxq_release(struct cnxk_eswitch_dev *eswitch_dev, uint16_t qid)
+{
+ struct roc_nix_rq *rq;
+ struct r
[PATCH v3 03/23] net/cnxk: eswitch HW resource configuration
Configuring the hardware resources used by the eswitch device.
Signed-off-by: Harman Kalra
---
drivers/net/cnxk/cnxk_eswitch.c | 223
1 file changed, 223 insertions(+)
diff --git a/drivers/net/cnxk/cnxk_eswitch.c b/drivers/net/cnxk/cnxk_eswitch.c
index c4ea3063ae..5712b71c3b 100644
--- a/drivers/net/cnxk/cnxk_eswitch.c
+++ b/drivers/net/cnxk/cnxk_eswitch.c
@@ -6,6 +6,47 @@
#define CNXK_NIX_DEF_SQ_COUNT 512
+static int
+eswitch_hw_rsrc_cleanup(struct cnxk_eswitch_dev *eswitch_dev, struct
rte_pci_device *pci_dev)
+{
+ struct roc_nix *nix;
+ int rc = 0;
+
+ nix = &eswitch_dev->nix;
+
+ roc_nix_unregister_queue_irqs(nix);
+ roc_nix_tm_fini(nix);
+ rc = roc_nix_lf_free(nix);
+ if (rc) {
+ plt_err("Failed to cleanup sq, rc %d", rc);
+ goto exit;
+ }
+
+ /* Check if this device is hosting common resource */
+ nix = roc_idev_npa_nix_get();
+ if (!nix || nix->pci_dev != pci_dev) {
+ rc = 0;
+ goto exit;
+ }
+
+ /* Try nix fini now */
+ rc = roc_nix_dev_fini(nix);
+ if (rc == -EAGAIN) {
+ plt_info("Common resource in use by other devices %s",
pci_dev->name);
+ goto exit;
+ } else if (rc) {
+ plt_err("Failed in nix dev fini, rc=%d", rc);
+ goto exit;
+ }
+
+ rte_free(eswitch_dev->txq);
+ rte_free(eswitch_dev->rxq);
+ rte_free(eswitch_dev->cxq);
+
+exit:
+ return rc;
+}
+
static int
cnxk_eswitch_dev_remove(struct rte_pci_device *pci_dev)
{
@@ -21,6 +62,9 @@ cnxk_eswitch_dev_remove(struct rte_pci_device *pci_dev)
goto exit;
}
+ /* Cleanup HW resources */
+ eswitch_hw_rsrc_cleanup(eswitch_dev, pci_dev);
+
rte_free(eswitch_dev);
exit:
return rc;
@@ -317,6 +361,177 @@ cnxk_eswitch_txq_setup(struct cnxk_eswitch_dev
*eswitch_dev, uint16_t qid, uint1
return rc;
}
+static int
+nix_lf_setup(struct cnxk_eswitch_dev *eswitch_dev)
+{
+ uint16_t nb_rxq, nb_txq, nb_cq;
+ struct roc_nix_fc_cfg fc_cfg;
+ struct roc_nix *nix;
+ uint64_t rx_cfg;
+ void *qs;
+ int rc;
+
+ /* Initialize base roc nix */
+ nix = &eswitch_dev->nix;
+ nix->pci_dev = eswitch_dev->pci_dev;
+ nix->hw_vlan_ins = true;
+ nix->reta_sz = ROC_NIX_RSS_RETA_SZ_256;
+ rc = roc_nix_dev_init(nix);
+ if (rc) {
+ plt_err("Failed to init nix eswitch device, rc=%d(%s)", rc,
roc_error_msg_get(rc));
+ goto fail;
+ }
+
+ /* Get the representors count */
+ rc = roc_nix_max_rep_count(&eswitch_dev->nix);
+ if (rc) {
+ plt_err("Failed to get rep cnt, rc=%d(%s)", rc,
roc_error_msg_get(rc));
+ goto free_cqs;
+ }
+
+ /* Allocating an NIX LF */
+ nb_rxq = CNXK_ESWITCH_MAX_RXQ;
+ nb_txq = CNXK_ESWITCH_MAX_TXQ;
+ nb_cq = CNXK_ESWITCH_MAX_RXQ;
+ rx_cfg = ROC_NIX_LF_RX_CFG_DIS_APAD;
+ rc = roc_nix_lf_alloc(nix, nb_rxq, nb_txq, rx_cfg);
+ if (rc) {
+ plt_err("lf alloc failed = %s(%d)", roc_error_msg_get(rc), rc);
+ goto dev_fini;
+ }
+
+ if (nb_rxq) {
+ /* Allocate memory for eswitch rq's and cq's */
+ qs = plt_zmalloc(sizeof(struct cnxk_eswitch_rxq) * nb_rxq, 0);
+ if (!qs) {
+ plt_err("Failed to alloc eswitch rxq");
+ goto lf_free;
+ }
+ eswitch_dev->rxq = qs;
+ }
+
+ if (nb_txq) {
+ /* Allocate memory for roc sq's */
+ qs = plt_zmalloc(sizeof(struct cnxk_eswitch_txq) * nb_txq, 0);
+ if (!qs) {
+ plt_err("Failed to alloc eswitch txq");
+ goto free_rqs;
+ }
+ eswitch_dev->txq = qs;
+ }
+
+ if (nb_cq) {
+ qs = plt_zmalloc(sizeof(struct cnxk_eswitch_cxq) * nb_cq, 0);
+ if (!qs) {
+ plt_err("Failed to alloc eswitch cxq");
+ goto free_sqs;
+ }
+ eswitch_dev->cxq = qs;
+ }
+
+ eswitch_dev->nb_rxq = nb_rxq;
+ eswitch_dev->nb_txq = nb_txq;
+
+ /* Re-enable NIX LF error interrupts */
+ roc_nix_err_intr_ena_dis(nix, true);
+ roc_nix_ras_intr_ena_dis(nix, true);
+
+ rc = roc_nix_lso_fmt_setup(nix);
+ if (rc) {
+ plt_err("lso setup failed = %s(%d)", roc_error_msg_get(rc), rc);
+ goto free_cqs;
+ }
+
+ rc = roc_nix_switch_hdr_set(nix, 0, 0, 0, 0);
+ if (rc) {
+ plt_err("switch hdr set failed = %s(%d)",
roc_error_msg_get(rc), rc);
+ goto free_cqs;
+ }
+
+ rc = roc_nix_rss_default_setup(nix,
+ FLOW_KE
[PATCH v3 04/23] net/cnxk: eswitch devargs parsing
Implementing the devargs parsing logic via which the representors
pattern is provided. These patterns define for which representies
representors shall be created.
Signed-off-by: Harman Kalra
---
drivers/net/cnxk/cnxk_eswitch.c | 88 +
drivers/net/cnxk/cnxk_eswitch.h | 52 ++
drivers/net/cnxk/cnxk_eswitch_devargs.c | 124
drivers/net/cnxk/meson.build| 1 +
4 files changed, 265 insertions(+)
create mode 100644 drivers/net/cnxk/cnxk_eswitch_devargs.c
diff --git a/drivers/net/cnxk/cnxk_eswitch.c b/drivers/net/cnxk/cnxk_eswitch.c
index 5712b71c3b..df1011cf7a 100644
--- a/drivers/net/cnxk/cnxk_eswitch.c
+++ b/drivers/net/cnxk/cnxk_eswitch.c
@@ -388,6 +388,7 @@ nix_lf_setup(struct cnxk_eswitch_dev *eswitch_dev)
plt_err("Failed to get rep cnt, rc=%d(%s)", rc,
roc_error_msg_get(rc));
goto free_cqs;
}
+ eswitch_dev->repr_cnt.max_repr = eswitch_dev->nix.rep_cnt;
/* Allocating an NIX LF */
nb_rxq = CNXK_ESWITCH_MAX_RXQ;
@@ -532,11 +533,73 @@ eswitch_hw_rsrc_setup(struct cnxk_eswitch_dev
*eswitch_dev, struct rte_pci_devic
return rc;
}
+int
+cnxk_eswitch_representor_info_get(struct cnxk_eswitch_dev *eswitch_dev,
+ struct rte_eth_representor_info *info)
+{
+ struct cnxk_eswitch_devargs *esw_da;
+ int rc = 0, n_entries, i, j = 0, k = 0;
+
+ for (i = 0; i < eswitch_dev->nb_esw_da; i++) {
+ for (j = 0; j < eswitch_dev->esw_da[i].nb_repr_ports; j++)
+ k++;
+ }
+ n_entries = k;
+
+ if (info == NULL)
+ goto out;
+
+ if ((uint32_t)n_entries > info->nb_ranges_alloc)
+ n_entries = info->nb_ranges_alloc;
+
+ k = 0;
+ info->controller = 0;
+ info->pf = 0;
+ for (i = 0; i < eswitch_dev->nb_esw_da; i++) {
+ esw_da = &eswitch_dev->esw_da[i];
+ info->ranges[k].type = esw_da->da.type;
+ switch (esw_da->da.type) {
+ case RTE_ETH_REPRESENTOR_PF:
+ info->ranges[k].controller = 0;
+ info->ranges[k].pf = esw_da->repr_hw_info[0].pfvf;
+ info->ranges[k].vf = 0;
+ info->ranges[k].id_base = info->ranges[i].pf;
+ info->ranges[k].id_end = info->ranges[i].pf;
+ snprintf(info->ranges[k].name,
sizeof(info->ranges[k].name), "pf%d",
+info->ranges[k].pf);
+ k++;
+ break;
+ case RTE_ETH_REPRESENTOR_VF:
+ for (j = 0; j < esw_da->nb_repr_ports; j++) {
+ info->ranges[k].controller = 0;
+ info->ranges[k].pf = esw_da->da.ports[0];
+ info->ranges[k].vf =
esw_da->repr_hw_info[j].pfvf;
+ info->ranges[k].id_base =
esw_da->repr_hw_info[j].port_id;
+ info->ranges[k].id_end =
esw_da->repr_hw_info[j].port_id;
+ snprintf(info->ranges[k].name,
sizeof(info->ranges[k].name),
+"pf%dvf%d", info->ranges[k].pf,
info->ranges[k].vf);
+ k++;
+ }
+ break;
+ default:
+ plt_err("Invalid type %d", esw_da->da.type);
+ rc = 0;
+ goto fail;
+ };
+ }
+ info->nb_ranges = k;
+fail:
+ return rc;
+out:
+ return n_entries;
+}
+
static int
cnxk_eswitch_dev_probe(struct rte_pci_driver *pci_drv, struct rte_pci_device
*pci_dev)
{
struct cnxk_eswitch_dev *eswitch_dev;
const struct rte_memzone *mz = NULL;
+ uint16_t num_reps;
int rc = -ENOMEM;
RTE_SET_USED(pci_drv);
@@ -569,12 +632,37 @@ cnxk_eswitch_dev_probe(struct rte_pci_driver *pci_drv,
struct rte_pci_device *pc
}
}
+ if (pci_dev->device.devargs) {
+ rc = cnxk_eswitch_repr_devargs(pci_dev, eswitch_dev);
+ if (rc)
+ goto rsrc_cleanup;
+ }
+
+ if (eswitch_dev->repr_cnt.nb_repr_created >
eswitch_dev->repr_cnt.max_repr) {
+ plt_err("Representors to be created %d can be greater than max
allowed %d",
+ eswitch_dev->repr_cnt.nb_repr_created,
eswitch_dev->repr_cnt.max_repr);
+ rc = -EINVAL;
+ goto rsrc_cleanup;
+ }
+
+ num_reps = eswitch_dev->repr_cnt.nb_repr_created;
+ if (!num_reps) {
+ plt_err("No representors enabled");
+ goto fail;
+ }
+
+ plt_esw_dbg("Max no of reps %d reps to be created %d Eswtch pfunc %x",
+ eswitch_dev->repr_cnt.max_repr,
e
[PATCH v3 05/23] net/cnxk: probing representor ports
Basic skeleton for probing representor devices. If PF device is
passed with "representor" devargs, representor ports gets probed
as a separate ethdev device.
Signed-off-by: Harman Kalra
---
MAINTAINERS | 1 +
doc/guides/nics/cnxk.rst| 35 +
drivers/net/cnxk/cnxk_eswitch.c | 12 ++
drivers/net/cnxk/cnxk_eswitch.h | 8 +-
drivers/net/cnxk/cnxk_rep.c | 256
drivers/net/cnxk/cnxk_rep.h | 50 +++
drivers/net/cnxk/cnxk_rep_ops.c | 129
drivers/net/cnxk/meson.build| 2 +
8 files changed, 492 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/cnxk/cnxk_rep.c
create mode 100644 drivers/net/cnxk/cnxk_rep.h
create mode 100644 drivers/net/cnxk/cnxk_rep_ops.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 0d1c8126e3..2716178e18 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -827,6 +827,7 @@ M: Nithin Dabilpuram
M: Kiran Kumar K
M: Sunil Kumar Kori
M: Satha Rao
+M: Harman Kalra
T: git://dpdk.org/next/dpdk-next-net-mrvl
F: drivers/common/cnxk/
F: drivers/net/cnxk/
diff --git a/doc/guides/nics/cnxk.rst b/doc/guides/nics/cnxk.rst
index 58cb8e2283..496474913f 100644
--- a/doc/guides/nics/cnxk.rst
+++ b/doc/guides/nics/cnxk.rst
@@ -37,6 +37,7 @@ Features of the CNXK Ethdev PMD are:
- Inline IPsec processing support
- Ingress meter support
- Queue based priority flow control support
+- Port representors
Prerequisites
-
@@ -613,6 +614,40 @@ Runtime Config Options for inline device
With the above configuration, driver would poll for aging flows every 50
seconds.
+Port Representors
+-
+
+The CNXK driver supports port representor model by adding virtual ethernet
+ports providing a logical representation in DPDK for physical function(PF) or
+SR-IOV virtual function (VF) devices for control and monitoring.
+
+Base device or parent device underneath the representor ports is a eswitch
+device which is not a cnxk ethernet device but has NIC RX and TX capabilities.
+Each representor port is represented by a RQ and SQ pair of this eswitch
+device.
+
+Implementation supports representors for both physical function and virtual
+function.
+
+Port representor ethdev instances can be spawned on an as needed basis
+through configuration parameters passed to the driver of the underlying
+base device using devargs ``-a ,representor=pf*vf*``
+
+.. note::
+
+ Representor ports to be created for respective representees should be
+ defined via standard representor devargs patterns
+ Eg. To create a representor for representee PF1VF0, devargs to be passed
+ is ``-a ,representor=pf01vf0``
+
+ Implementation supports creation of multiple port representors with pattern:
+ ``-a ,representor=[pf0vf[1,2],pf1vf[2-5]]``
+
+Port representor PMD supports following operations:
+
+- Get PF/VF statistics
+- Flow operations - create, validate, destroy, query, flush, dump
+
Debugging Options
-
diff --git a/drivers/net/cnxk/cnxk_eswitch.c b/drivers/net/cnxk/cnxk_eswitch.c
index df1011cf7a..4b2c907f9f 100644
--- a/drivers/net/cnxk/cnxk_eswitch.c
+++ b/drivers/net/cnxk/cnxk_eswitch.c
@@ -3,6 +3,7 @@
*/
#include
+#include
#define CNXK_NIX_DEF_SQ_COUNT 512
@@ -62,6 +63,10 @@ cnxk_eswitch_dev_remove(struct rte_pci_device *pci_dev)
goto exit;
}
+ /* Remove representor devices associated with PF */
+ if (eswitch_dev->repr_cnt.nb_repr_created)
+ cnxk_rep_dev_remove(eswitch_dev);
+
/* Cleanup HW resources */
eswitch_hw_rsrc_cleanup(eswitch_dev, pci_dev);
@@ -655,6 +660,13 @@ cnxk_eswitch_dev_probe(struct rte_pci_driver *pci_drv,
struct rte_pci_device *pc
eswitch_dev->repr_cnt.max_repr,
eswitch_dev->repr_cnt.nb_repr_created,
roc_nix_get_pf_func(&eswitch_dev->nix));
+ /* Probe representor ports */
+ rc = cnxk_rep_dev_probe(pci_dev, eswitch_dev);
+ if (rc) {
+ plt_err("Failed to probe representor ports");
+ goto rsrc_cleanup;
+ }
+
/* Spinlock for synchronization between representors traffic and control
* messages
*/
diff --git a/drivers/net/cnxk/cnxk_eswitch.h b/drivers/net/cnxk/cnxk_eswitch.h
index 6ff296399e..dcd5add6d0 100644
--- a/drivers/net/cnxk/cnxk_eswitch.h
+++ b/drivers/net/cnxk/cnxk_eswitch.h
@@ -66,6 +66,11 @@ struct cnxk_eswitch_repr_cnt {
uint16_t nb_repr_started;
};
+struct cnxk_eswitch_switch_domain {
+ uint16_t switch_domain_id;
+ uint16_t pf;
+};
+
struct cnxk_rep_info {
struct rte_eth_dev *rep_eth_dev;
};
@@ -121,7 +126,8 @@ struct cnxk_eswitch_dev {
/* Port representor fields */
rte_spinlock_t rep_lock;
- uint16_t switch_domain_id;
+ uint16_t nb_switch_domain;
+ struct cnxk_eswitch_switch_domain sw_dom[RTE_MAX_ETHPORTS];
uint16_t eswitch_vdev;
struct cnxk_rep_info *rep
[PATCH v3 06/23] common/cnxk: common NPC changes for eswitch
Adding new MCAM API for installing flow using generic npc_install_flow
mbox and other helper APIs. Also adding rss action configuration for
eswitch.
Signed-off-by: Harman Kalra
---
drivers/common/cnxk/meson.build| 1 +
drivers/common/cnxk/roc_api.h | 3 +
drivers/common/cnxk/roc_eswitch.c | 306 +
drivers/common/cnxk/roc_eswitch.h | 22 +++
drivers/common/cnxk/roc_mbox.h | 33
drivers/common/cnxk/roc_npc.c | 26 ++-
drivers/common/cnxk/roc_npc.h | 5 +-
drivers/common/cnxk/roc_npc_mcam.c | 2 +-
drivers/common/cnxk/roc_npc_priv.h | 3 +-
drivers/common/cnxk/version.map| 6 +
10 files changed, 398 insertions(+), 9 deletions(-)
create mode 100644 drivers/common/cnxk/roc_eswitch.c
create mode 100644 drivers/common/cnxk/roc_eswitch.h
diff --git a/drivers/common/cnxk/meson.build b/drivers/common/cnxk/meson.build
index 56eea52909..e0e4600989 100644
--- a/drivers/common/cnxk/meson.build
+++ b/drivers/common/cnxk/meson.build
@@ -20,6 +20,7 @@ sources = files(
'roc_cpt_debug.c',
'roc_dev.c',
'roc_dpi.c',
+'roc_eswitch.c',
'roc_hash.c',
'roc_idev.c',
'roc_irq.c',
diff --git a/drivers/common/cnxk/roc_api.h b/drivers/common/cnxk/roc_api.h
index f630853088..6a86863c57 100644
--- a/drivers/common/cnxk/roc_api.h
+++ b/drivers/common/cnxk/roc_api.h
@@ -117,4 +117,7 @@
/* MACsec */
#include "roc_mcs.h"
+/* Eswitch */
+#include "roc_eswitch.h"
+
#endif /* _ROC_API_H_ */
diff --git a/drivers/common/cnxk/roc_eswitch.c
b/drivers/common/cnxk/roc_eswitch.c
new file mode 100644
index 00..e480ab1046
--- /dev/null
+++ b/drivers/common/cnxk/roc_eswitch.c
@@ -0,0 +1,306 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2024 Marvell.
+ */
+
+#include
+
+#include "roc_api.h"
+#include "roc_priv.h"
+
+static int
+eswitch_vlan_rx_cfg(uint16_t pcifunc, struct mbox *mbox)
+{
+ struct nix_vtag_config *vtag_cfg;
+ int rc;
+
+ vtag_cfg = mbox_alloc_msg_nix_vtag_cfg(mbox_get(mbox));
+ if (!vtag_cfg) {
+ rc = -EINVAL;
+ goto exit;
+ }
+
+ /* config strip, capture and size */
+ vtag_cfg->hdr.pcifunc = pcifunc;
+ vtag_cfg->vtag_size = NIX_VTAGSIZE_T4;
+ vtag_cfg->cfg_type = VTAG_RX; /* rx vlan cfg */
+ vtag_cfg->rx.vtag_type = NIX_RX_VTAG_TYPE0;
+ vtag_cfg->rx.strip_vtag = true;
+ vtag_cfg->rx.capture_vtag = true;
+
+ rc = mbox_process(mbox);
+ if (rc)
+ goto exit;
+
+ rc = 0;
+exit:
+ mbox_put(mbox);
+ return rc;
+}
+
+static int
+eswitch_vlan_tx_cfg(struct roc_npc_flow *flow, uint16_t pcifunc, struct mbox
*mbox,
+ uint16_t vlan_tci, uint16_t *vidx)
+{
+ struct nix_vtag_config *vtag_cfg;
+ struct nix_vtag_config_rsp *rsp;
+ int rc;
+
+ union {
+ uint64_t reg;
+ struct nix_tx_vtag_action_s act;
+ } tx_vtag_action;
+
+ vtag_cfg = mbox_alloc_msg_nix_vtag_cfg(mbox_get(mbox));
+ if (!vtag_cfg) {
+ rc = -EINVAL;
+ goto exit;
+ }
+
+ /* Insert vlan tag */
+ vtag_cfg->hdr.pcifunc = pcifunc;
+ vtag_cfg->vtag_size = NIX_VTAGSIZE_T4;
+ vtag_cfg->cfg_type = VTAG_TX; /* tx vlan cfg */
+ vtag_cfg->tx.cfg_vtag0 = true;
+ vtag_cfg->tx.vtag0 = (((uint32_t)ROC_ESWITCH_VLAN_TPID << 16) |
vlan_tci);
+
+ rc = mbox_process_msg(mbox, (void *)&rsp);
+ if (rc)
+ goto exit;
+
+ if (rsp->vtag0_idx < 0) {
+ plt_err("Failed to config TX VTAG action");
+ rc = -EINVAL;
+ goto exit;
+ }
+
+ *vidx = rsp->vtag0_idx;
+ tx_vtag_action.reg = 0;
+ tx_vtag_action.act.vtag0_def = rsp->vtag0_idx;
+ tx_vtag_action.act.vtag0_lid = NPC_LID_LA;
+ tx_vtag_action.act.vtag0_op = NIX_TX_VTAGOP_INSERT;
+ tx_vtag_action.act.vtag0_relptr = NIX_TX_VTAGACTION_VTAG0_RELPTR;
+
+ flow->vtag_action = tx_vtag_action.reg;
+
+ rc = 0;
+exit:
+ mbox_put(mbox);
+ return rc;
+}
+
+int
+roc_eswitch_npc_mcam_tx_rule(struct roc_npc *roc_npc, struct roc_npc_flow
*flow, uint16_t pcifunc,
+uint32_t vlan_tci)
+{
+ struct npc *npc = roc_npc_to_npc_priv(roc_npc);
+ struct npc_install_flow_req *req;
+ struct npc_install_flow_rsp *rsp;
+ struct mbox *mbox = npc->mbox;
+ uint16_t vidx = 0, lbkid;
+ int rc;
+
+ rc = eswitch_vlan_tx_cfg(flow, roc_npc->pf_func, mbox, vlan_tci, &vidx);
+ if (rc) {
+ plt_err("Failed to configure VLAN TX, err %d", rc);
+ goto fail;
+ }
+
+ req = mbox_alloc_msg_npc_install_flow(mbox_get(mbox));
+ if (!req) {
+ rc = -EINVAL;
+ goto exit;
+ }
+
+ lbkid = 0;
+ req->hdr.pcifunc = roc_npc->pf_func; /* Eswitch PF is requester */
[PATCH v3 07/23] common/cnxk: interface to update VLAN TPID
Introducing eswitch variant of set vlan tpid api which can be
using for PF and VF
Signed-off-by: Harman Kalra
---
drivers/common/cnxk/roc_eswitch.c | 15 +++
drivers/common/cnxk/roc_eswitch.h | 4
drivers/common/cnxk/roc_nix_priv.h | 11 +--
drivers/common/cnxk/roc_nix_vlan.c | 23 ++-
drivers/common/cnxk/version.map| 1 +
5 files changed, 43 insertions(+), 11 deletions(-)
diff --git a/drivers/common/cnxk/roc_eswitch.c
b/drivers/common/cnxk/roc_eswitch.c
index e480ab1046..020a891a32 100644
--- a/drivers/common/cnxk/roc_eswitch.c
+++ b/drivers/common/cnxk/roc_eswitch.c
@@ -304,3 +304,18 @@ roc_eswitch_npc_rss_action_configure(struct roc_npc
*roc_npc, struct roc_npc_flo
((uint64_t)(rss_grp_idx & NPC_RSS_ACT_GRP_MASK) <<
NPC_RSS_ACT_GRP_OFFSET);
return 0;
}
+
+int
+roc_eswitch_nix_vlan_tpid_set(struct roc_nix *roc_nix, uint32_t type, uint16_t
tpid, bool is_vf)
+{
+ struct nix *nix = roc_nix_to_nix_priv(roc_nix);
+ struct dev *dev = &nix->dev;
+ int rc;
+
+ /* Configuring for PF/VF */
+ rc = nix_vlan_tpid_set(dev->mbox, dev->pf_func | is_vf, type, tpid);
+ if (rc)
+ plt_err("Failed to set tpid for PF, rc %d", rc);
+
+ return rc;
+}
diff --git a/drivers/common/cnxk/roc_eswitch.h
b/drivers/common/cnxk/roc_eswitch.h
index cdbe808a71..34b75d10ac 100644
--- a/drivers/common/cnxk/roc_eswitch.h
+++ b/drivers/common/cnxk/roc_eswitch.h
@@ -19,4 +19,8 @@ int __roc_api roc_eswitch_npc_mcam_delete_rule(struct roc_npc
*roc_npc, struct r
int __roc_api roc_eswitch_npc_rss_action_configure(struct roc_npc *roc_npc,
struct roc_npc_flow *flow,
uint32_t flowkey_cfg,
uint16_t *reta_tbl);
+
+/* NIX */
+int __roc_api roc_eswitch_nix_vlan_tpid_set(struct roc_nix *nix, uint32_t
type, uint16_t tpid,
+ bool is_vf);
#endif /* __ROC_ESWITCH_H__ */
diff --git a/drivers/common/cnxk/roc_nix_priv.h
b/drivers/common/cnxk/roc_nix_priv.h
index a582b9df33..3d99ade2b4 100644
--- a/drivers/common/cnxk/roc_nix_priv.h
+++ b/drivers/common/cnxk/roc_nix_priv.h
@@ -469,13 +469,12 @@ void nix_tm_shaper_profile_free(struct
nix_tm_shaper_profile *profile);
uint64_t nix_get_blkaddr(struct dev *dev);
void nix_lf_rq_dump(__io struct nix_cn10k_rq_ctx_s *ctx, FILE *file);
int nix_lf_gen_reg_dump(uintptr_t nix_lf_base, uint64_t *data);
-int nix_lf_stat_reg_dump(uintptr_t nix_lf_base, uint64_t *data,
-uint8_t lf_tx_stats, uint8_t lf_rx_stats);
-int nix_lf_int_reg_dump(uintptr_t nix_lf_base, uint64_t *data, uint16_t qints,
- uint16_t cints);
-int nix_q_ctx_get(struct dev *dev, uint8_t ctype, uint16_t qid,
- __io void **ctx_p);
+int nix_lf_stat_reg_dump(uintptr_t nix_lf_base, uint64_t *data, uint8_t
lf_tx_stats,
+uint8_t lf_rx_stats);
+int nix_lf_int_reg_dump(uintptr_t nix_lf_base, uint64_t *data, uint16_t qints,
uint16_t cints);
+int nix_q_ctx_get(struct dev *dev, uint8_t ctype, uint16_t qid, __io void
**ctx_p);
uint8_t nix_tm_lbk_relchan_get(struct nix *nix);
+int nix_vlan_tpid_set(struct mbox *mbox, uint16_t pcifunc, uint32_t type,
uint16_t tpid);
/*
* Telemetry
diff --git a/drivers/common/cnxk/roc_nix_vlan.c
b/drivers/common/cnxk/roc_nix_vlan.c
index abd2eb0571..db218593ad 100644
--- a/drivers/common/cnxk/roc_nix_vlan.c
+++ b/drivers/common/cnxk/roc_nix_vlan.c
@@ -211,18 +211,17 @@ roc_nix_vlan_insert_ena_dis(struct roc_nix *roc_nix,
}
int
-roc_nix_vlan_tpid_set(struct roc_nix *roc_nix, uint32_t type, uint16_t tpid)
+nix_vlan_tpid_set(struct mbox *mbox, uint16_t pcifunc, uint32_t type, uint16_t
tpid)
{
- struct nix *nix = roc_nix_to_nix_priv(roc_nix);
- struct dev *dev = &nix->dev;
- struct mbox *mbox = mbox_get(dev->mbox);
struct nix_set_vlan_tpid *tpid_cfg;
int rc = -ENOSPC;
- tpid_cfg = mbox_alloc_msg_nix_set_vlan_tpid(mbox);
+ /* Configuring for PF */
+ tpid_cfg = mbox_alloc_msg_nix_set_vlan_tpid(mbox_get(mbox));
if (tpid_cfg == NULL)
goto exit;
tpid_cfg->tpid = tpid;
+ tpid_cfg->hdr.pcifunc = pcifunc;
if (type & ROC_NIX_VLAN_TYPE_OUTER)
tpid_cfg->vlan_type = NIX_VLAN_TYPE_OUTER;
@@ -234,3 +233,17 @@ roc_nix_vlan_tpid_set(struct roc_nix *roc_nix, uint32_t
type, uint16_t tpid)
mbox_put(mbox);
return rc;
}
+
+int
+roc_nix_vlan_tpid_set(struct roc_nix *roc_nix, uint32_t type, uint16_t tpid)
+{
+ struct nix *nix = roc_nix_to_nix_priv(roc_nix);
+ struct dev *dev = &nix->dev;
+ int rc;
+
+ rc = nix_vlan_tpid_set(dev->mbox, dev->pf_func, type, tpid);
+ if (rc)
+ plt_err("Failed to set tpid for PF, rc %d", rc);
+
+ return rc;
+}
diff --git a/drivers/common/cnxk/version.map b/drivers/common/
[PATCH v3 08/23] net/cnxk: eswitch flow configurations
Adding flow rules for eswitch PF and VF and implementing
interfaces to delete, shift flow rules
Signed-off-by: Harman Kalra
---
drivers/net/cnxk/cnxk_eswitch.c | 44 +++
drivers/net/cnxk/cnxk_eswitch.h | 25 +-
drivers/net/cnxk/cnxk_eswitch_devargs.c | 1 +
drivers/net/cnxk/cnxk_eswitch_flow.c| 454
drivers/net/cnxk/meson.build| 1 +
5 files changed, 522 insertions(+), 3 deletions(-)
create mode 100644 drivers/net/cnxk/cnxk_eswitch_flow.c
diff --git a/drivers/net/cnxk/cnxk_eswitch.c b/drivers/net/cnxk/cnxk_eswitch.c
index 4b2c907f9f..6f651e0857 100644
--- a/drivers/net/cnxk/cnxk_eswitch.c
+++ b/drivers/net/cnxk/cnxk_eswitch.c
@@ -2,11 +2,33 @@
* Copyright(C) 2024 Marvell.
*/
+#include
+
#include
#include
#define CNXK_NIX_DEF_SQ_COUNT 512
+struct cnxk_esw_repr_hw_info *
+cnxk_eswitch_representor_hw_info(struct cnxk_eswitch_dev *eswitch_dev,
uint16_t hw_func)
+{
+ struct cnxk_eswitch_devargs *esw_da;
+ int i, j;
+
+ if (!eswitch_dev)
+ return NULL;
+
+ /* Traversing the initialized represented list */
+ for (i = 0; i < eswitch_dev->nb_esw_da; i++) {
+ esw_da = &eswitch_dev->esw_da[i];
+ for (j = 0; j < esw_da->nb_repr_ports; j++) {
+ if (esw_da->repr_hw_info[j].hw_func == hw_func)
+ return &esw_da->repr_hw_info[j];
+ }
+ }
+ return NULL;
+}
+
static int
eswitch_hw_rsrc_cleanup(struct cnxk_eswitch_dev *eswitch_dev, struct
rte_pci_device *pci_dev)
{
@@ -67,6 +89,10 @@ cnxk_eswitch_dev_remove(struct rte_pci_device *pci_dev)
if (eswitch_dev->repr_cnt.nb_repr_created)
cnxk_rep_dev_remove(eswitch_dev);
+ /* Cleanup NPC rxtx flow rules */
+ cnxk_eswitch_flow_rules_remove_list(eswitch_dev,
&eswitch_dev->esw_flow_list,
+ eswitch_dev->npc.pf_func);
+
/* Cleanup HW resources */
eswitch_hw_rsrc_cleanup(eswitch_dev, pci_dev);
@@ -87,6 +113,21 @@ cnxk_eswitch_nix_rsrc_start(struct cnxk_eswitch_dev
*eswitch_dev)
goto done;
}
+ /* Install eswitch PF mcam rules */
+ rc = cnxk_eswitch_pfvf_flow_rules_install(eswitch_dev, false);
+ if (rc) {
+ plt_err("Failed to install rxtx rules, rc %d", rc);
+ goto done;
+ }
+
+ /* Configure TPID for Eswitch PF LFs */
+ rc = roc_eswitch_nix_vlan_tpid_set(&eswitch_dev->nix,
ROC_NIX_VLAN_TYPE_OUTER,
+ CNXK_ESWITCH_VLAN_TPID, false);
+ if (rc) {
+ plt_err("Failed to configure tpid, rc %d", rc);
+ goto done;
+ }
+
rc = roc_npc_mcam_enable_all_entries(&eswitch_dev->npc, 1);
if (rc) {
plt_err("Failed to enable NPC entries %d", rc);
@@ -531,6 +572,9 @@ eswitch_hw_rsrc_setup(struct cnxk_eswitch_dev *eswitch_dev,
struct rte_pci_devic
if (rc)
goto rsrc_cleanup;
+ /* List for eswitch default flows */
+ TAILQ_INIT(&eswitch_dev->esw_flow_list);
+
return rc;
rsrc_cleanup:
eswitch_hw_rsrc_cleanup(eswitch_dev, pci_dev);
diff --git a/drivers/net/cnxk/cnxk_eswitch.h b/drivers/net/cnxk/cnxk_eswitch.h
index dcd5add6d0..5b4e1b0a71 100644
--- a/drivers/net/cnxk/cnxk_eswitch.h
+++ b/drivers/net/cnxk/cnxk_eswitch.h
@@ -13,11 +13,10 @@
#include "cn10k_tx.h"
#define CNXK_ESWITCH_CTRL_MSG_SOCK_PATH "/tmp/cxk_rep_ctrl_msg_sock"
+#define CNXK_ESWITCH_VLAN_TPID ROC_ESWITCH_VLAN_TPID
#define CNXK_REP_ESWITCH_DEV_MZ"cnxk_eswitch_dev"
-#define CNXK_ESWITCH_VLAN_TPID 0x8100
#define CNXK_ESWITCH_MAX_TXQ 256
#define CNXK_ESWITCH_MAX_RXQ 256
-#define CNXK_ESWITCH_LBK_CHAN 63
#define CNXK_ESWITCH_VFPF_SHIFT8
#define CNXK_ESWITCH_QUEUE_STATE_RELEASED 0
@@ -25,6 +24,7 @@
#define CNXK_ESWITCH_QUEUE_STATE_STARTED2
#define CNXK_ESWITCH_QUEUE_STATE_STOPPED3
+TAILQ_HEAD(eswitch_flow_list, roc_npc_flow);
enum cnxk_esw_da_pattern_type {
CNXK_ESW_DA_TYPE_LIST = 0,
CNXK_ESW_DA_TYPE_PFVF,
@@ -39,6 +39,9 @@ struct cnxk_esw_repr_hw_info {
uint16_t pfvf;
/* representor port id assigned to representee */
uint16_t port_id;
+ uint16_t num_flow_entries;
+
+ TAILQ_HEAD(flow_list, roc_npc_flow) repr_flow_list;
};
/* Structure representing per devarg information - this can be per representee
@@ -90,7 +93,6 @@ struct cnxk_eswitch_cxq {
uint8_t state;
};
-TAILQ_HEAD(eswitch_flow_list, roc_npc_flow);
struct cnxk_eswitch_dev {
/* Input parameters */
struct plt_pci_device *pci_dev;
@@ -116,6 +118,13 @@ struct cnxk_eswitch_dev {
uint16_t rep_cnt;
uint8_t configured;
+ /* NPC rxtx rules */
+ struct flow_list esw_flow_list;
+ uint16_t num_entries;
+
[PATCH v3 09/23] net/cnxk: eswitch fastpath routines
Implementing fastpath RX and TX fast path routines which can be
invoked from respective representors rx burst and tx burst
Signed-off-by: Harman Kalra
---
drivers/net/cnxk/cnxk_eswitch.h | 5 +
drivers/net/cnxk/cnxk_eswitch_rxtx.c | 211 +++
drivers/net/cnxk/meson.build | 1 +
3 files changed, 217 insertions(+)
create mode 100644 drivers/net/cnxk/cnxk_eswitch_rxtx.c
diff --git a/drivers/net/cnxk/cnxk_eswitch.h b/drivers/net/cnxk/cnxk_eswitch.h
index 5b4e1b0a71..4edfa91bdc 100644
--- a/drivers/net/cnxk/cnxk_eswitch.h
+++ b/drivers/net/cnxk/cnxk_eswitch.h
@@ -177,4 +177,9 @@ int cnxk_eswitch_pfvf_flow_rules_install(struct
cnxk_eswitch_dev *eswitch_dev, b
int cnxk_eswitch_flow_rule_shift(uint16_t hw_func, uint16_t *new_entry);
int cnxk_eswitch_flow_rules_remove_list(struct cnxk_eswitch_dev *eswitch_dev,
struct flow_list *list, uint16_t
hw_func);
+/* RX TX fastpath routines */
+uint16_t cnxk_eswitch_dev_tx_burst(struct cnxk_eswitch_dev *eswitch_dev,
uint16_t qid,
+ struct rte_mbuf **pkts, uint16_t nb_tx,
const uint16_t flags);
+uint16_t cnxk_eswitch_dev_rx_burst(struct cnxk_eswitch_dev *eswitch_dev,
uint16_t qid,
+ struct rte_mbuf **pkts, uint16_t nb_pkts);
#endif /* __CNXK_ESWITCH_H__ */
diff --git a/drivers/net/cnxk/cnxk_eswitch_rxtx.c
b/drivers/net/cnxk/cnxk_eswitch_rxtx.c
new file mode 100644
index 00..d57e32b091
--- /dev/null
+++ b/drivers/net/cnxk/cnxk_eswitch_rxtx.c
@@ -0,0 +1,211 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2024 Marvell.
+ */
+
+#include
+
+static __rte_always_inline struct rte_mbuf *
+eswitch_nix_get_mbuf_from_cqe(void *cq, const uint64_t data_off)
+{
+ rte_iova_t buff;
+
+ /* Skip CQE, NIX_RX_PARSE_S and SG HDR(9 DWORDs) and peek buff addr */
+ buff = *((rte_iova_t *)((uint64_t *)cq + 9));
+ return (struct rte_mbuf *)(buff - data_off);
+}
+
+static inline uint64_t
+eswitch_nix_rx_nb_pkts(struct roc_nix_cq *cq, const uint64_t wdata, const
uint32_t qmask)
+{
+ uint64_t reg, head, tail;
+ uint32_t available;
+
+ /* Update the available count if cached value is not enough */
+
+ /* Use LDADDA version to avoid reorder */
+ reg = roc_atomic64_add_sync(wdata, cq->status);
+ /* CQ_OP_STATUS operation error */
+ if (reg & BIT_ULL(NIX_CQ_OP_STAT_OP_ERR) || reg &
BIT_ULL(NIX_CQ_OP_STAT_CQ_ERR))
+ return 0;
+
+ tail = reg & 0xF;
+ head = (reg >> 20) & 0xF;
+ if (tail < head)
+ available = tail - head + qmask + 1;
+ else
+ available = tail - head;
+
+ return available;
+}
+
+static inline void
+nix_cn9k_xmit_one(uint64_t *cmd, void *lmt_addr, const plt_iova_t io_addr)
+{
+ uint64_t lmt_status;
+
+ do {
+ roc_lmt_mov(lmt_addr, cmd, 0);
+ lmt_status = roc_lmt_submit_ldeor(io_addr);
+ } while (lmt_status == 0);
+}
+
+uint16_t
+cnxk_eswitch_dev_tx_burst(struct cnxk_eswitch_dev *eswitch_dev, uint16_t qid,
+ struct rte_mbuf **pkts, uint16_t nb_xmit, const
uint16_t flags)
+{
+ struct roc_nix_sq *sq = &eswitch_dev->txq[qid].sqs;
+ struct roc_nix_rq *rq = &eswitch_dev->rxq[qid].rqs;
+ uint64_t aura_handle, cmd[6], data = 0;
+ uint16_t lmt_id, pkt = 0, nb_tx = 0;
+ struct nix_send_ext_s *send_hdr_ext;
+ struct nix_send_hdr_s *send_hdr;
+ uint16_t vlan_tci = qid;
+ union nix_send_sg_s *sg;
+ uintptr_t lmt_base, pa;
+ int64_t fc_pkts, dw_m1;
+ rte_iova_t io_addr;
+
+ if (unlikely(eswitch_dev->txq[qid].state !=
CNXK_ESWITCH_QUEUE_STATE_STARTED))
+ return 0;
+
+ lmt_base = sq->roc_nix->lmt_base;
+ io_addr = sq->io_addr;
+ aura_handle = rq->aura_handle;
+ /* Get LMT base address and LMT ID as per thread ID */
+ lmt_id = roc_plt_control_lmt_id_get();
+ lmt_base += ((uint64_t)lmt_id << ROC_LMT_LINE_SIZE_LOG2);
+ /* Double word minus 1: LMTST size-1 in units of 128 bits */
+ /* 2(HDR) + 2(EXT_HDR) + 1(SG) + 1(IOVA) = 6/2 - 1 = 2 */
+ dw_m1 = cn10k_nix_tx_ext_subs(flags) + 1;
+
+ memset(cmd, 0, sizeof(cmd));
+ send_hdr = (struct nix_send_hdr_s *)&cmd[0];
+ send_hdr->w0.sizem1 = dw_m1;
+ send_hdr->w0.sq = sq->qid;
+
+ if (dw_m1 >= 2) {
+ send_hdr_ext = (struct nix_send_ext_s *)&cmd[2];
+ send_hdr_ext->w0.subdc = NIX_SUBDC_EXT;
+ if (flags & NIX_TX_OFFLOAD_VLAN_QINQ_F) {
+ send_hdr_ext->w1.vlan0_ins_ena = true;
+ /* 2B before end of l2 header */
+ send_hdr_ext->w1.vlan0_ins_ptr = 12;
+ send_hdr_ext->w1.vlan0_ins_tci = 0;
+ }
+ sg = (union nix_send_sg_s *)&cmd[4];
+ } else {
+
[PATCH v3 10/23] net/cnxk: add representor control plane
Implementing the control path for representor ports, where represented
ports can be configured using TLV messaging.
Signed-off-by: Harman Kalra
---
drivers/net/cnxk/cnxk_eswitch.c | 70 ++-
drivers/net/cnxk/cnxk_eswitch.h | 8 +
drivers/net/cnxk/cnxk_rep.c | 52 ++
drivers/net/cnxk/cnxk_rep.h | 3 +
drivers/net/cnxk/cnxk_rep_msg.c | 827
drivers/net/cnxk/cnxk_rep_msg.h | 95
drivers/net/cnxk/meson.build| 1 +
7 files changed, 1048 insertions(+), 8 deletions(-)
create mode 100644 drivers/net/cnxk/cnxk_rep_msg.c
create mode 100644 drivers/net/cnxk/cnxk_rep_msg.h
diff --git a/drivers/net/cnxk/cnxk_eswitch.c b/drivers/net/cnxk/cnxk_eswitch.c
index 6f651e0857..ad6834410d 100644
--- a/drivers/net/cnxk/cnxk_eswitch.c
+++ b/drivers/net/cnxk/cnxk_eswitch.c
@@ -9,6 +9,27 @@
#define CNXK_NIX_DEF_SQ_COUNT 512
+int
+cnxk_eswitch_representor_id(struct cnxk_eswitch_dev *eswitch_dev, uint16_t
hw_func,
+ uint16_t *rep_id)
+{
+ struct cnxk_esw_repr_hw_info *repr_info;
+ int rc = 0;
+
+ repr_info = cnxk_eswitch_representor_hw_info(eswitch_dev, hw_func);
+ if (!repr_info) {
+ plt_warn("Failed to get representor group for %x", hw_func);
+ rc = -ENOENT;
+ goto fail;
+ }
+
+ *rep_id = repr_info->rep_id;
+
+ return 0;
+fail:
+ return rc;
+}
+
struct cnxk_esw_repr_hw_info *
cnxk_eswitch_representor_hw_info(struct cnxk_eswitch_dev *eswitch_dev,
uint16_t hw_func)
{
@@ -86,8 +107,41 @@ cnxk_eswitch_dev_remove(struct rte_pci_device *pci_dev)
}
/* Remove representor devices associated with PF */
- if (eswitch_dev->repr_cnt.nb_repr_created)
+ if (eswitch_dev->repr_cnt.nb_repr_created) {
+ /* Exiting the rep msg ctrl thread */
+ if (eswitch_dev->start_ctrl_msg_thrd) {
+ uint32_t sunlen;
+ struct sockaddr_un sun = {0};
+ int sock_fd = 0;
+
+ eswitch_dev->start_ctrl_msg_thrd = false;
+ if (!eswitch_dev->client_connected) {
+ plt_esw_dbg("Establishing connection for
teardown");
+ sock_fd = socket(AF_UNIX, SOCK_STREAM, 0);
+ if (sock_fd == -1) {
+ plt_err("Failed to open socket. err
%d", -errno);
+ return -errno;
+ }
+ sun.sun_family = AF_UNIX;
+ sunlen = sizeof(struct sockaddr_un);
+ strncpy(sun.sun_path,
CNXK_ESWITCH_CTRL_MSG_SOCK_PATH,
+ sizeof(sun.sun_path) - 1);
+
+ if (connect(sock_fd, (struct sockaddr *)&sun,
sunlen) < 0) {
+ plt_err("Failed to connect socket: %s,
err %d",
+
CNXK_ESWITCH_CTRL_MSG_SOCK_PATH, errno);
+ close(sock_fd);
+ return -errno;
+ }
+ }
+ rte_thread_join(eswitch_dev->rep_ctrl_msg_thread, NULL);
+ if (!eswitch_dev->client_connected)
+ close(sock_fd);
+ }
+
+ /* Remove representor devices associated with PF */
cnxk_rep_dev_remove(eswitch_dev);
+ }
/* Cleanup NPC rxtx flow rules */
cnxk_eswitch_flow_rules_remove_list(eswitch_dev,
&eswitch_dev->esw_flow_list,
@@ -106,13 +160,6 @@ cnxk_eswitch_nix_rsrc_start(struct cnxk_eswitch_dev
*eswitch_dev)
{
int rc;
- /* Enable Rx in NPC */
- rc = roc_nix_npc_rx_ena_dis(&eswitch_dev->nix, true);
- if (rc) {
- plt_err("Failed to enable NPC rx %d", rc);
- goto done;
- }
-
/* Install eswitch PF mcam rules */
rc = cnxk_eswitch_pfvf_flow_rules_install(eswitch_dev, false);
if (rc) {
@@ -128,6 +175,13 @@ cnxk_eswitch_nix_rsrc_start(struct cnxk_eswitch_dev
*eswitch_dev)
goto done;
}
+ /* Enable Rx in NPC */
+ rc = roc_nix_npc_rx_ena_dis(&eswitch_dev->nix, true);
+ if (rc) {
+ plt_err("Failed to enable NPC rx %d", rc);
+ goto done;
+ }
+
rc = roc_npc_mcam_enable_all_entries(&eswitch_dev->npc, 1);
if (rc) {
plt_err("Failed to enable NPC entries %d", rc);
diff --git a/drivers/net/cnxk/cnxk_eswitch.h b/drivers/net/cnxk/cnxk_eswitch.h
index 4edfa91bdc..ecf10a8e08 100644
--- a/drivers/net/cnxk/cnxk_eswitch.h
+++ b/drivers/net/cnxk/cnxk_eswitch.h
@@ -133,6 +133,12 @@ struct cnxk_eswitch_dev {
/* No of representors */
struct cnxk_e
[PATCH v3 11/23] common/cnxk: representee notification callback
Setting up a callback which gets invoked every time a representee
comes up or goes down. Later this callback gets handled by network
conterpart.
Signed-off-by: Harman Kalra
---
drivers/common/cnxk/roc_dev.c | 24
drivers/common/cnxk/roc_dev_priv.h | 3 +++
drivers/common/cnxk/roc_eswitch.c | 23 +++
drivers/common/cnxk/roc_eswitch.h | 6 ++
drivers/common/cnxk/roc_mbox.c | 2 ++
drivers/common/cnxk/roc_mbox.h | 11 ++-
drivers/common/cnxk/version.map| 2 ++
7 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/drivers/common/cnxk/roc_dev.c b/drivers/common/cnxk/roc_dev.c
index 084343c3b4..3564dbe647 100644
--- a/drivers/common/cnxk/roc_dev.c
+++ b/drivers/common/cnxk/roc_dev.c
@@ -537,6 +537,29 @@ pf_vf_mbox_send_up_msg(struct dev *dev, void *rec_msg)
}
}
+static int
+mbox_up_handler_rep_repte_notify(struct dev *dev, struct rep_repte_req *req,
struct msg_rsp *rsp)
+{
+ int rc = 0;
+
+ plt_base_dbg("pf:%d/vf:%d msg id 0x%x (%s) from: pf:%d/vf:%d",
dev_get_pf(dev->pf_func),
+dev_get_vf(dev->pf_func), req->hdr.id,
mbox_id2name(req->hdr.id),
+dev_get_pf(req->hdr.pcifunc),
dev_get_vf(req->hdr.pcifunc));
+
+ plt_base_dbg("repte pcifunc %x, enable %d", req->repte_pcifunc,
req->enable);
+
+ if (dev->ops && dev->ops->repte_notify) {
+ rc = dev->ops->repte_notify(dev->roc_nix, req->repte_pcifunc,
+ req->enable);
+ if (rc < 0)
+ plt_err("Failed to sent new representee %x notification
to %s",
+ req->repte_pcifunc, (req->enable == true) ?
"enable" : "disable");
+ }
+
+ rsp->hdr.rc = rc;
+ return rc;
+}
+
static int
mbox_up_handler_mcs_intr_notify(struct dev *dev, struct mcs_intr_info *info,
struct msg_rsp *rsp)
{
@@ -711,6 +734,7 @@ mbox_process_msgs_up(struct dev *dev, struct mbox_msghdr
*req)
}
MBOX_UP_CGX_MESSAGES
MBOX_UP_MCS_MESSAGES
+ MBOX_UP_REP_MESSAGES
#undef M
}
diff --git a/drivers/common/cnxk/roc_dev_priv.h
b/drivers/common/cnxk/roc_dev_priv.h
index 5b2c5096f8..dd694b8572 100644
--- a/drivers/common/cnxk/roc_dev_priv.h
+++ b/drivers/common/cnxk/roc_dev_priv.h
@@ -36,12 +36,15 @@ typedef void (*q_err_cb_t)(void *roc_nix, void *data);
/* Link status get callback */
typedef void (*link_status_get_t)(void *roc_nix,
struct cgx_link_user_info *link);
+/* Representee notification callback */
+typedef int (*repte_notify_t)(void *roc_nix, uint16_t pf_func, bool enable);
struct dev_ops {
link_info_t link_status_update;
ptp_info_t ptp_info_update;
link_status_get_t link_status_get;
q_err_cb_t q_err_cb;
+ repte_notify_t repte_notify;
};
#define dev_is_vf(dev) ((dev)->hwcap & DEV_HWCAP_F_VF)
diff --git a/drivers/common/cnxk/roc_eswitch.c
b/drivers/common/cnxk/roc_eswitch.c
index 020a891a32..14819bad75 100644
--- a/drivers/common/cnxk/roc_eswitch.c
+++ b/drivers/common/cnxk/roc_eswitch.c
@@ -319,3 +319,26 @@ roc_eswitch_nix_vlan_tpid_set(struct roc_nix *roc_nix,
uint32_t type, uint16_t t
return rc;
}
+
+int
+roc_eswitch_nix_process_repte_notify_cb_register(struct roc_nix *roc_nix,
+process_repte_notify_t
proc_repte_nt)
+{
+ struct nix *nix = roc_nix_to_nix_priv(roc_nix);
+ struct dev *dev = &nix->dev;
+
+ if (proc_repte_nt == NULL)
+ return NIX_ERR_PARAM;
+
+ dev->ops->repte_notify = (repte_notify_t)proc_repte_nt;
+ return 0;
+}
+
+void
+roc_eswitch_nix_process_repte_notify_cb_unregister(struct roc_nix *roc_nix)
+{
+ struct nix *nix = roc_nix_to_nix_priv(roc_nix);
+ struct dev *dev = &nix->dev;
+
+ dev->ops->repte_notify = NULL;
+}
diff --git a/drivers/common/cnxk/roc_eswitch.h
b/drivers/common/cnxk/roc_eswitch.h
index 34b75d10ac..f99f7e2981 100644
--- a/drivers/common/cnxk/roc_eswitch.h
+++ b/drivers/common/cnxk/roc_eswitch.h
@@ -8,6 +8,9 @@
#define ROC_ESWITCH_VLAN_TPID 0x8100
#define ROC_ESWITCH_LBK_CHAN 63
+/* Process representee notification callback */
+typedef int (*process_repte_notify_t)(void *roc_nix, uint16_t pf_func, bool
enable);
+
/* NPC */
int __roc_api roc_eswitch_npc_mcam_rx_rule(struct roc_npc *roc_npc, struct
roc_npc_flow *flow,
uint16_t pcifunc, uint16_t vlan_tci,
@@ -23,4 +26,7 @@ int __roc_api roc_eswitch_npc_rss_action_configure(struct
roc_npc *roc_npc,
/* NIX */
int __roc_api roc_eswitch_nix_vlan_tpid_set(struct roc_nix *nix, uint32_t
type, uint16_t tpid,
bool is_vf);
+int __roc_api roc_eswitch_nix_process_repte_notify_cb_register(struct roc_nix
*roc_nix,
+ process_repte
[PATCH v3 12/23] net/cnxk: handling representee notification
In case of any representee coming up or going down, kernel sends a
mbox up call which signals a thread to process these messages and
enable/disable HW resources accordingly.
Signed-off-by: Harman Kalra
---
drivers/net/cnxk/cnxk_eswitch.c | 8 +
drivers/net/cnxk/cnxk_eswitch.h | 20 +++
drivers/net/cnxk/cnxk_rep.c | 263
drivers/net/cnxk/cnxk_rep.h | 36 +
4 files changed, 327 insertions(+)
diff --git a/drivers/net/cnxk/cnxk_eswitch.c b/drivers/net/cnxk/cnxk_eswitch.c
index ad6834410d..79f44de06e 100644
--- a/drivers/net/cnxk/cnxk_eswitch.c
+++ b/drivers/net/cnxk/cnxk_eswitch.c
@@ -139,6 +139,14 @@ cnxk_eswitch_dev_remove(struct rte_pci_device *pci_dev)
close(sock_fd);
}
+ if (eswitch_dev->repte_msg_proc.start_thread) {
+ eswitch_dev->repte_msg_proc.start_thread = false;
+
pthread_cond_signal(&eswitch_dev->repte_msg_proc.repte_msg_cond);
+
rte_thread_join(eswitch_dev->repte_msg_proc.repte_msg_thread, NULL);
+
pthread_mutex_destroy(&eswitch_dev->repte_msg_proc.mutex);
+
pthread_cond_destroy(&eswitch_dev->repte_msg_proc.repte_msg_cond);
+ }
+
/* Remove representor devices associated with PF */
cnxk_rep_dev_remove(eswitch_dev);
}
diff --git a/drivers/net/cnxk/cnxk_eswitch.h b/drivers/net/cnxk/cnxk_eswitch.h
index ecf10a8e08..1baf198d72 100644
--- a/drivers/net/cnxk/cnxk_eswitch.h
+++ b/drivers/net/cnxk/cnxk_eswitch.h
@@ -30,6 +30,23 @@ enum cnxk_esw_da_pattern_type {
CNXK_ESW_DA_TYPE_PFVF,
};
+struct cnxk_esw_repte_msg {
+ uint16_t hw_func;
+ bool enable;
+
+ TAILQ_ENTRY(cnxk_esw_repte_msg) next;
+};
+
+struct cnxk_esw_repte_msg_proc {
+ bool start_thread;
+ uint8_t msg_avail;
+ rte_thread_t repte_msg_thread;
+ pthread_cond_t repte_msg_cond;
+ pthread_mutex_t mutex;
+
+ TAILQ_HEAD(esw_repte_msg_list, cnxk_esw_repte_msg) msg_list;
+};
+
struct cnxk_esw_repr_hw_info {
/* Representee pcifunc value */
uint16_t hw_func;
@@ -139,6 +156,9 @@ struct cnxk_eswitch_dev {
bool client_connected;
int sock_fd;
+ /* Representee notification */
+ struct cnxk_esw_repte_msg_proc repte_msg_proc;
+
/* Port representor fields */
rte_spinlock_t rep_lock;
uint16_t nb_switch_domain;
diff --git a/drivers/net/cnxk/cnxk_rep.c b/drivers/net/cnxk/cnxk_rep.c
index 5b619ebb9e..11901dac87 100644
--- a/drivers/net/cnxk/cnxk_rep.c
+++ b/drivers/net/cnxk/cnxk_rep.c
@@ -4,6 +4,8 @@
#include
#include
+#define REPTE_MSG_PROC_THRD_NAME_MAX_LEN 30
+
#define PF_SHIFT 10
#define PF_MASK 0x3F
@@ -86,6 +88,7 @@ cnxk_rep_dev_remove(struct cnxk_eswitch_dev *eswitch_dev)
{
int i, rc = 0;
+ roc_eswitch_nix_process_repte_notify_cb_unregister(&eswitch_dev->nix);
for (i = 0; i < eswitch_dev->nb_switch_domain; i++) {
rc =
rte_eth_switch_domain_free(eswitch_dev->sw_dom[i].switch_domain_id);
if (rc)
@@ -95,6 +98,236 @@ cnxk_rep_dev_remove(struct cnxk_eswitch_dev *eswitch_dev)
return rc;
}
+static int
+cnxk_representee_release(struct cnxk_eswitch_dev *eswitch_dev, uint16_t
hw_func)
+{
+ struct cnxk_rep_dev *rep_dev = NULL;
+ struct rte_eth_dev *rep_eth_dev;
+ int i, rc = 0;
+
+ for (i = 0; i < eswitch_dev->repr_cnt.nb_repr_probed; i++) {
+ rep_eth_dev = eswitch_dev->rep_info[i].rep_eth_dev;
+ if (!rep_eth_dev) {
+ plt_err("Failed to get rep ethdev handle");
+ rc = -EINVAL;
+ goto done;
+ }
+
+ rep_dev = cnxk_rep_pmd_priv(rep_eth_dev);
+ if (rep_dev->hw_func == hw_func &&
+ (!rep_dev->native_repte || rep_dev->is_vf_active)) {
+ rep_dev->is_vf_active = false;
+ rc = cnxk_rep_dev_stop(rep_eth_dev);
+ if (rc) {
+ plt_err("Failed to stop repr port %d, rep id
%d", rep_dev->port_id,
+ rep_dev->rep_id);
+ goto done;
+ }
+
+ cnxk_rep_rx_queue_release(rep_eth_dev, 0);
+ cnxk_rep_tx_queue_release(rep_eth_dev, 0);
+ plt_rep_dbg("Released representor ID %d representing
%x", rep_dev->rep_id,
+ hw_func);
+ break;
+ }
+ }
+done:
+ return rc;
+}
+
+static int
+cnxk_representee_setup(struct cnxk_eswitch_dev *eswitch_dev, uint16_t hw_func,
uint16_t rep_id)
+{
+ struct cnxk_rep_dev *rep_dev = NULL;
+ struct rte_eth_dev *rep_eth_dev;
+ int i, rc = 0;
+
+ for
[PATCH v3 13/23] net/cnxk: representor ethdev ops
Implementing ethernet device operation callbacks for
port representors PMD
Signed-off-by: Harman Kalra
---
drivers/net/cnxk/cnxk_rep.c | 28 +-
drivers/net/cnxk/cnxk_rep.h | 35 +++
drivers/net/cnxk/cnxk_rep_msg.h | 8 +
drivers/net/cnxk/cnxk_rep_ops.c | 495 ++--
4 files changed, 523 insertions(+), 43 deletions(-)
diff --git a/drivers/net/cnxk/cnxk_rep.c b/drivers/net/cnxk/cnxk_rep.c
index 11901dac87..27940e7e97 100644
--- a/drivers/net/cnxk/cnxk_rep.c
+++ b/drivers/net/cnxk/cnxk_rep.c
@@ -73,6 +73,8 @@ cnxk_rep_state_update(struct cnxk_eswitch_dev *eswitch_dev,
uint16_t hw_func, ui
int
cnxk_rep_dev_uninit(struct rte_eth_dev *ethdev)
{
+ struct cnxk_rep_dev *rep_dev = cnxk_rep_pmd_priv(ethdev);
+
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;
@@ -80,6 +82,8 @@ cnxk_rep_dev_uninit(struct rte_eth_dev *ethdev)
rte_free(ethdev->data->mac_addrs);
ethdev->data->mac_addrs = NULL;
+ rep_dev->parent_dev->repr_cnt.nb_repr_probed--;
+
return 0;
}
@@ -369,26 +373,6 @@ cnxk_rep_parent_setup(struct cnxk_eswitch_dev *eswitch_dev)
return rc;
}
-static uint16_t
-cnxk_rep_tx_burst(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
-{
- PLT_SET_USED(tx_queue);
- PLT_SET_USED(tx_pkts);
- PLT_SET_USED(nb_pkts);
-
- return 0;
-}
-
-static uint16_t
-cnxk_rep_rx_burst(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
-{
- PLT_SET_USED(rx_queue);
- PLT_SET_USED(rx_pkts);
- PLT_SET_USED(nb_pkts);
-
- return 0;
-}
-
static int
cnxk_rep_dev_init(struct rte_eth_dev *eth_dev, void *params)
{
@@ -418,8 +402,8 @@ cnxk_rep_dev_init(struct rte_eth_dev *eth_dev, void *params)
eth_dev->dev_ops = &cnxk_rep_dev_ops;
/* Rx/Tx functions stubs to avoid crashing */
- eth_dev->rx_pkt_burst = cnxk_rep_rx_burst;
- eth_dev->tx_pkt_burst = cnxk_rep_tx_burst;
+ eth_dev->rx_pkt_burst = cnxk_rep_rx_burst_dummy;
+ eth_dev->tx_pkt_burst = cnxk_rep_tx_burst_dummy;
/* Only single queues for representor devices */
eth_dev->data->nb_rx_queues = 1;
diff --git a/drivers/net/cnxk/cnxk_rep.h b/drivers/net/cnxk/cnxk_rep.h
index bee141e25b..b57b56cd12 100644
--- a/drivers/net/cnxk/cnxk_rep.h
+++ b/drivers/net/cnxk/cnxk_rep.h
@@ -7,6 +7,13 @@
#ifndef __CNXK_REP_H__
#define __CNXK_REP_H__
+#define CNXK_REP_TX_OFFLOAD_CAPA
\
+ (RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE | RTE_ETH_TX_OFFLOAD_VLAN_INSERT |
\
+RTE_ETH_TX_OFFLOAD_MULTI_SEGS)
+
+#define CNXK_REP_RX_OFFLOAD_CAPA
\
+ (RTE_ETH_RX_OFFLOAD_SCATTER | RTE_ETH_RX_OFFLOAD_RSS_HASH |
RTE_ETH_RX_OFFLOAD_VLAN_STRIP)
+
/* Common ethdev ops */
extern struct eth_dev_ops cnxk_rep_dev_ops;
@@ -57,12 +64,33 @@ struct cnxk_rep_dev {
uint8_t mac_addr[RTE_ETHER_ADDR_LEN];
};
+/* Inline functions */
+static inline void
+cnxk_rep_lock(struct cnxk_rep_dev *rep)
+{
+ rte_spinlock_lock(&rep->parent_dev->rep_lock);
+}
+
+static inline void
+cnxk_rep_unlock(struct cnxk_rep_dev *rep)
+{
+ rte_spinlock_unlock(&rep->parent_dev->rep_lock);
+}
+
static inline struct cnxk_rep_dev *
cnxk_rep_pmd_priv(const struct rte_eth_dev *eth_dev)
{
return eth_dev->data->dev_private;
}
+static __rte_always_inline void
+cnxk_rep_pool_buffer_stats(struct rte_mempool *pool)
+{
+ plt_rep_dbg("pool %s size %d buffer count in use %d available
%d\n", pool->name,
+ pool->size, rte_mempool_in_use_count(pool),
rte_mempool_avail_count(pool));
+}
+
+/* Prototypes */
int cnxk_rep_dev_probe(struct rte_pci_device *pci_dev, struct cnxk_eswitch_dev
*eswitch_dev);
int cnxk_rep_dev_remove(struct cnxk_eswitch_dev *eswitch_dev);
int cnxk_rep_dev_uninit(struct rte_eth_dev *ethdev);
@@ -85,5 +113,12 @@ int cnxk_rep_stats_get(struct rte_eth_dev *eth_dev, struct
rte_eth_stats *stats)
int cnxk_rep_stats_reset(struct rte_eth_dev *eth_dev);
int cnxk_rep_flow_ops_get(struct rte_eth_dev *ethdev, const struct
rte_flow_ops **ops);
int cnxk_rep_state_update(struct cnxk_eswitch_dev *eswitch_dev, uint16_t
hw_func, uint16_t *rep_id);
+int cnxk_rep_promiscuous_enable(struct rte_eth_dev *ethdev);
+int cnxk_rep_promiscuous_disable(struct rte_eth_dev *ethdev);
+int cnxk_rep_mac_addr_set(struct rte_eth_dev *eth_dev, struct rte_ether_addr
*addr);
+uint16_t cnxk_rep_tx_burst_dummy(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts);
+uint16_t cnxk_rep_rx_burst_dummy(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts);
+void cnxk_rep_tx_queue_stop(struct rte_eth_dev *ethdev, uint16_t queue_id);
+void cnxk_rep_rx_queue_stop(struct rte_eth_dev *ethdev, uint16_t queue_id);
#endif /* __CNXK_REP_H__ */
diff --git a/drivers/net/cnxk/cnxk_rep_msg.h b/drivers/net/c
[PATCH v3 14/23] common/cnxk: get representees ethernet stats
Implementing an mbox interface to fetch the representees's ethernet
stats from the kernel.
Signed-off-by: Harman Kalra
---
drivers/common/cnxk/roc_eswitch.c | 45 +++
drivers/common/cnxk/roc_eswitch.h | 2 ++
drivers/common/cnxk/roc_mbox.h| 30 +
drivers/common/cnxk/version.map | 1 +
4 files changed, 78 insertions(+)
diff --git a/drivers/common/cnxk/roc_eswitch.c
b/drivers/common/cnxk/roc_eswitch.c
index 14819bad75..c67b4090a5 100644
--- a/drivers/common/cnxk/roc_eswitch.c
+++ b/drivers/common/cnxk/roc_eswitch.c
@@ -342,3 +342,48 @@ roc_eswitch_nix_process_repte_notify_cb_unregister(struct
roc_nix *roc_nix)
dev->ops->repte_notify = NULL;
}
+
+int
+roc_eswitch_nix_repte_stats(struct roc_nix *roc_nix, uint16_t pf_func, struct
roc_nix_stats *stats)
+{
+ struct nix *nix = roc_nix_to_nix_priv(roc_nix);
+ struct dev *dev = &nix->dev;
+ struct nix_get_lf_stats_req *req;
+ struct nix_lf_stats_rsp *rsp;
+ struct mbox *mbox;
+ int rc;
+
+ mbox = mbox_get(dev->mbox);
+ req = mbox_alloc_msg_nix_get_lf_stats(mbox);
+ if (!req) {
+ rc = -ENOSPC;
+ goto exit;
+ }
+
+ req->hdr.pcifunc = roc_nix_get_pf_func(roc_nix);
+ req->pcifunc = pf_func;
+
+ rc = mbox_process_msg(mbox, (void *)&rsp);
+ if (rc)
+ goto exit;
+
+ stats->rx_octs = rsp->rx.octs;
+ stats->rx_ucast = rsp->rx.ucast;
+ stats->rx_bcast = rsp->rx.bcast;
+ stats->rx_mcast = rsp->rx.mcast;
+ stats->rx_drop = rsp->rx.drop;
+ stats->rx_drop_octs = rsp->rx.drop_octs;
+ stats->rx_drop_bcast = rsp->rx.drop_bcast;
+ stats->rx_drop_mcast = rsp->rx.drop_mcast;
+ stats->rx_err = rsp->rx.err;
+
+ stats->tx_ucast = rsp->tx.ucast;
+ stats->tx_bcast = rsp->tx.bcast;
+ stats->tx_mcast = rsp->tx.mcast;
+ stats->tx_drop = rsp->tx.drop;
+ stats->tx_octs = rsp->tx.octs;
+
+exit:
+ mbox_put(mbox);
+ return rc;
+}
diff --git a/drivers/common/cnxk/roc_eswitch.h
b/drivers/common/cnxk/roc_eswitch.h
index f99f7e2981..5a0b7419c8 100644
--- a/drivers/common/cnxk/roc_eswitch.h
+++ b/drivers/common/cnxk/roc_eswitch.h
@@ -26,6 +26,8 @@ int __roc_api roc_eswitch_npc_rss_action_configure(struct
roc_npc *roc_npc,
/* NIX */
int __roc_api roc_eswitch_nix_vlan_tpid_set(struct roc_nix *nix, uint32_t
type, uint16_t tpid,
bool is_vf);
+int __roc_api roc_eswitch_nix_repte_stats(struct roc_nix *roc_nix, uint16_t
pf_func,
+ struct roc_nix_stats *stats);
int __roc_api roc_eswitch_nix_process_repte_notify_cb_register(struct roc_nix
*roc_nix,
process_repte_notify_t
proc_repte_nt);
void __roc_api roc_eswitch_nix_process_repte_notify_cb_unregister(struct
roc_nix *roc_nix);
diff --git a/drivers/common/cnxk/roc_mbox.h b/drivers/common/cnxk/roc_mbox.h
index 9de48c1907..39c1132792 100644
--- a/drivers/common/cnxk/roc_mbox.h
+++ b/drivers/common/cnxk/roc_mbox.h
@@ -304,6 +304,7 @@ struct mbox_msghdr {
M(NIX_MCAST_GRP_DESTROY, 0x802c, nix_mcast_grp_destroy,
nix_mcast_grp_destroy_req, msg_rsp)\
M(NIX_MCAST_GRP_UPDATE, 0x802d, nix_mcast_grp_update,
nix_mcast_grp_update_req,\
nix_mcast_grp_update_rsp)
\
+ M(NIX_GET_LF_STATS,0x802e, nix_get_lf_stats, nix_get_lf_stats_req,
nix_lf_stats_rsp) \
/* MCS mbox IDs (range 0xa000 - 0xbFFF) */
\
M(MCS_ALLOC_RESOURCES, 0xa000, mcs_alloc_resources, mcs_alloc_rsrc_req,
\
mcs_alloc_rsrc_rsp)
\
@@ -1847,6 +1848,35 @@ struct nix_mcast_grp_update_rsp {
uint32_t __io mce_start_index;
};
+struct nix_get_lf_stats_req {
+ struct mbox_msghdr hdr;
+ uint16_t __io pcifunc;
+ uint64_t __io rsvd;
+};
+
+struct nix_lf_stats_rsp {
+ struct mbox_msghdr hdr;
+ struct {
+ uint64_t __io octs;
+ uint64_t __io ucast;
+ uint64_t __io bcast;
+ uint64_t __io mcast;
+ uint64_t __io drop;
+ uint64_t __io drop_octs;
+ uint64_t __io drop_mcast;
+ uint64_t __io drop_bcast;
+ uint64_t __io err;
+ uint64_t __io rsvd[5];
+ } rx;
+ struct {
+ uint64_t __io ucast;
+ uint64_t __io bcast;
+ uint64_t __io mcast;
+ uint64_t __io drop;
+ uint64_t __io octs;
+ } tx;
+};
+
/* Global NIX inline IPSec configuration */
struct nix_inline_ipsec_cfg {
struct mbox_msghdr hdr;
diff --git a/drivers/common/cnxk/version.map b/drivers/common/cnxk/v
[PATCH v3 15/23] net/cnxk: ethernet statistic for representor
Adding representor ethernet statistics support which can fetch stats
for representees which are operating independently or part of
companian app.
Signed-off-by: Harman Kalra
---
drivers/net/cnxk/cnxk_rep_msg.h | 7 ++
drivers/net/cnxk/cnxk_rep_ops.c | 140 +++-
2 files changed, 143 insertions(+), 4 deletions(-)
diff --git a/drivers/net/cnxk/cnxk_rep_msg.h b/drivers/net/cnxk/cnxk_rep_msg.h
index 63cfbe3f19..277e25d92a 100644
--- a/drivers/net/cnxk/cnxk_rep_msg.h
+++ b/drivers/net/cnxk/cnxk_rep_msg.h
@@ -21,6 +21,8 @@ typedef enum CNXK_REP_MSG {
CNXK_REP_MSG_EXIT,
/* Ethernet operation msgs */
CNXK_REP_MSG_ETH_SET_MAC,
+ CNXK_REP_MSG_ETH_STATS_GET,
+ CNXK_REP_MSG_ETH_STATS_CLEAR,
/* End of messaging sequence */
CNXK_REP_MSG_END,
} cnxk_rep_msg_t;
@@ -89,6 +91,11 @@ typedef struct cnxk_rep_msg_eth_mac_set_meta {
uint8_t addr_bytes[RTE_ETHER_ADDR_LEN];
} __rte_packed cnxk_rep_msg_eth_set_mac_meta_t;
+/* Ethernet op - get/clear stats */
+typedef struct cnxk_rep_msg_eth_stats_meta {
+ uint16_t portid;
+} __rte_packed cnxk_rep_msg_eth_stats_meta_t;
+
void cnxk_rep_msg_populate_command(void *buffer, uint32_t *length,
cnxk_rep_msg_t type,
uint32_t size);
void cnxk_rep_msg_populate_command_meta(void *buffer, uint32_t *length, void
*msg_meta, uint32_t sz,
diff --git a/drivers/net/cnxk/cnxk_rep_ops.c b/drivers/net/cnxk/cnxk_rep_ops.c
index 97643a50f2..6728b3e265 100644
--- a/drivers/net/cnxk/cnxk_rep_ops.c
+++ b/drivers/net/cnxk/cnxk_rep_ops.c
@@ -486,19 +486,151 @@ cnxk_rep_tx_queue_release(struct rte_eth_dev *ethdev,
uint16_t queue_id)
plt_err("Failed to release txq %d, rc=%d", rc, txq->qid);
}
+static int
+process_eth_stats(struct cnxk_rep_dev *rep_dev, cnxk_rep_msg_ack_data_t
*adata, cnxk_rep_msg_t msg)
+{
+ cnxk_rep_msg_eth_stats_meta_t msg_st_meta;
+ uint32_t len = 0, rc;
+ void *buffer;
+ size_t size;
+
+ size = CNXK_REP_MSG_MAX_BUFFER_SZ;
+ buffer = plt_zmalloc(size, 0);
+ if (!buffer) {
+ plt_err("Failed to allocate mem");
+ rc = -ENOMEM;
+ goto fail;
+ }
+
+ cnxk_rep_msg_populate_header(buffer, &len);
+
+ msg_st_meta.portid = rep_dev->rep_id;
+ cnxk_rep_msg_populate_command_meta(buffer, &len, &msg_st_meta,
+
sizeof(cnxk_rep_msg_eth_stats_meta_t), msg);
+ cnxk_rep_msg_populate_msg_end(buffer, &len);
+
+ rc = cnxk_rep_msg_send_process(rep_dev, buffer, len, adata);
+ if (rc) {
+ plt_err("Failed to process the message, err %d", rc);
+ goto fail;
+ }
+
+ rte_free(buffer);
+
+ return 0;
+fail:
+ rte_free(buffer);
+ return rc;
+}
+
+static int
+native_repte_eth_stats(struct cnxk_rep_dev *rep_dev, struct rte_eth_stats
*stats)
+{
+ struct roc_nix_stats nix_stats;
+ int rc = 0;
+
+ rc = roc_eswitch_nix_repte_stats(&rep_dev->parent_dev->nix,
rep_dev->hw_func, &nix_stats);
+ if (rc) {
+ plt_err("Failed to get stats for representee %x, err %d",
rep_dev->hw_func, rc);
+ goto fail;
+ }
+
+ memset(stats, 0, sizeof(struct rte_eth_stats));
+ stats->opackets = nix_stats.tx_ucast;
+ stats->opackets += nix_stats.tx_mcast;
+ stats->opackets += nix_stats.tx_bcast;
+ stats->oerrors = nix_stats.tx_drop;
+ stats->obytes = nix_stats.tx_octs;
+
+ stats->ipackets = nix_stats.rx_ucast;
+ stats->ipackets += nix_stats.rx_mcast;
+ stats->ipackets += nix_stats.rx_bcast;
+ stats->imissed = nix_stats.rx_drop;
+ stats->ibytes = nix_stats.rx_octs;
+ stats->ierrors = nix_stats.rx_err;
+
+ return 0;
+fail:
+ return rc;
+}
+
int
cnxk_rep_stats_get(struct rte_eth_dev *ethdev, struct rte_eth_stats *stats)
{
- PLT_SET_USED(ethdev);
- PLT_SET_USED(stats);
+ struct cnxk_rep_dev *rep_dev = cnxk_rep_pmd_priv(ethdev);
+ struct rte_eth_stats vf_stats;
+ cnxk_rep_msg_ack_data_t adata;
+ int rc;
+
+ /* If representor not representing any active VF, return 0 */
+ if (!rep_dev->is_vf_active)
+ return 0;
+
+ if (rep_dev->native_repte) {
+ /* For representees which are independent */
+ rc = native_repte_eth_stats(rep_dev, &vf_stats);
+ if (rc) {
+ plt_err("Failed to get stats for vf rep %x (hw_func
%x), err %d",
+ rep_dev->port_id, rep_dev->hw_func, rc);
+ goto fail;
+ }
+ } else {
+ /* For representees which are part of companian app */
+ rc = process_eth_stats(rep_dev, &adata,
CNXK_REP_MSG_ETH_STATS_GET);
+ if (rc || adata.u.sval < 0) {
+ if (adata.u.sval < 0)
+
[PATCH v3 16/23] common/cnxk: base support for eswitch VF
Base ROC layer changes for supporting eswitch VF and NIX lbk
changes for ESW
Signed-off-by: Harman Kalra
---
drivers/common/cnxk/roc_constants.h | 1 +
drivers/common/cnxk/roc_dev.c | 1 +
drivers/common/cnxk/roc_nix.c | 15 +--
drivers/common/cnxk/roc_nix.h | 1 +
drivers/common/cnxk/roc_nix_priv.h | 1 +
drivers/common/cnxk/version.map | 1 +
6 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/common/cnxk/roc_constants.h
b/drivers/common/cnxk/roc_constants.h
index cb4edbea58..21b3998cee 100644
--- a/drivers/common/cnxk/roc_constants.h
+++ b/drivers/common/cnxk/roc_constants.h
@@ -44,6 +44,7 @@
#define PCI_DEVID_CNXK_RVU_REE_PF 0xA0f4
#define PCI_DEVID_CNXK_RVU_REE_VF 0xA0f5
#define PCI_DEVID_CNXK_RVU_ESWITCH_PF 0xA0E0
+#define PCI_DEVID_CNXK_RVU_ESWITCH_VF 0xA0E1
#define PCI_DEVID_CN9K_CGX 0xA059
#define PCI_DEVID_CN10K_RPM 0xA060
diff --git a/drivers/common/cnxk/roc_dev.c b/drivers/common/cnxk/roc_dev.c
index 3564dbe647..0e83a92c43 100644
--- a/drivers/common/cnxk/roc_dev.c
+++ b/drivers/common/cnxk/roc_dev.c
@@ -1224,6 +1224,7 @@ dev_vf_hwcap_update(struct plt_pci_device *pci_dev,
struct dev *dev)
case PCI_DEVID_CNXK_RVU_VF:
case PCI_DEVID_CNXK_RVU_SDP_VF:
case PCI_DEVID_CNXK_RVU_NIX_INL_VF:
+ case PCI_DEVID_CNXK_RVU_ESWITCH_VF:
dev->hwcap |= DEV_HWCAP_F_VF;
break;
}
diff --git a/drivers/common/cnxk/roc_nix.c b/drivers/common/cnxk/roc_nix.c
index 7e327a7e6e..f1eaca3ab4 100644
--- a/drivers/common/cnxk/roc_nix.c
+++ b/drivers/common/cnxk/roc_nix.c
@@ -13,6 +13,14 @@ roc_nix_is_lbk(struct roc_nix *roc_nix)
return nix->lbk_link;
}
+bool
+roc_nix_is_esw(struct roc_nix *roc_nix)
+{
+ struct nix *nix = roc_nix_to_nix_priv(roc_nix);
+
+ return nix->esw_link;
+}
+
int
roc_nix_get_base_chan(struct roc_nix *roc_nix)
{
@@ -156,7 +164,7 @@ roc_nix_max_pkt_len(struct roc_nix *roc_nix)
if (roc_model_is_cn9k())
return NIX_CN9K_MAX_HW_FRS;
- if (nix->lbk_link)
+ if (nix->lbk_link || nix->esw_link)
return NIX_LBK_MAX_HW_FRS;
return NIX_RPM_MAX_HW_FRS;
@@ -349,7 +357,7 @@ roc_nix_get_hw_info(struct roc_nix *roc_nix)
rc = mbox_process_msg(mbox, (void *)&hw_info);
if (rc == 0) {
nix->vwqe_interval = hw_info->vwqe_delay;
- if (nix->lbk_link)
+ if (nix->lbk_link || nix->esw_link)
roc_nix->dwrr_mtu = hw_info->lbk_dwrr_mtu;
else if (nix->sdp_link)
roc_nix->dwrr_mtu = hw_info->sdp_dwrr_mtu;
@@ -366,6 +374,7 @@ sdp_lbk_id_update(struct plt_pci_device *pci_dev, struct
nix *nix)
{
nix->sdp_link = false;
nix->lbk_link = false;
+ nix->esw_link = false;
/* Update SDP/LBK link based on PCI device id */
switch (pci_dev->id.device_id) {
@@ -374,7 +383,9 @@ sdp_lbk_id_update(struct plt_pci_device *pci_dev, struct
nix *nix)
nix->sdp_link = true;
break;
case PCI_DEVID_CNXK_RVU_AF_VF:
+ case PCI_DEVID_CNXK_RVU_ESWITCH_VF:
nix->lbk_link = true;
+ nix->esw_link = true;
break;
default:
break;
diff --git a/drivers/common/cnxk/roc_nix.h b/drivers/common/cnxk/roc_nix.h
index b369335fc4..ffea84dae8 100644
--- a/drivers/common/cnxk/roc_nix.h
+++ b/drivers/common/cnxk/roc_nix.h
@@ -527,6 +527,7 @@ int __roc_api roc_nix_dev_fini(struct roc_nix *roc_nix);
/* Type */
bool __roc_api roc_nix_is_lbk(struct roc_nix *roc_nix);
+bool __roc_api roc_nix_is_esw(struct roc_nix *roc_nix);
bool __roc_api roc_nix_is_sdp(struct roc_nix *roc_nix);
bool __roc_api roc_nix_is_pf(struct roc_nix *roc_nix);
bool __roc_api roc_nix_is_vf_or_sdp(struct roc_nix *roc_nix);
diff --git a/drivers/common/cnxk/roc_nix_priv.h
b/drivers/common/cnxk/roc_nix_priv.h
index 3d99ade2b4..275ffc8ea3 100644
--- a/drivers/common/cnxk/roc_nix_priv.h
+++ b/drivers/common/cnxk/roc_nix_priv.h
@@ -170,6 +170,7 @@ struct nix {
uintptr_t base;
bool sdp_link;
bool lbk_link;
+ bool esw_link;
bool ptp_en;
bool is_nix1;
diff --git a/drivers/common/cnxk/version.map b/drivers/common/cnxk/version.map
index 87c9d7511f..cdb46d8739 100644
--- a/drivers/common/cnxk/version.map
+++ b/drivers/common/cnxk/version.map
@@ -276,6 +276,7 @@ INTERNAL {
roc_nix_inl_outb_cpt_lfs_dump;
roc_nix_cpt_ctx_cache_sync;
roc_nix_is_lbk;
+ roc_nix_is_esw;
roc_nix_is_pf;
roc_nix_is_sdp;
roc_nix_is_vf_or_sdp;
--
2.18.0
[PATCH v3 17/23] net/cnxk: eswitch VF as ethernet device
Adding support for eswitch VF to probe as normal cnxk ethernet device
Signed-off-by: Harman Kalra
---
drivers/net/cnxk/cn10k_ethdev.c| 1 +
drivers/net/cnxk/cnxk_ethdev.c | 41 +-
drivers/net/cnxk/cnxk_ethdev.h | 3 +++
drivers/net/cnxk/cnxk_ethdev_ops.c | 4 +++
drivers/net/cnxk/cnxk_link.c | 3 ++-
5 files changed, 39 insertions(+), 13 deletions(-)
diff --git a/drivers/net/cnxk/cn10k_ethdev.c b/drivers/net/cnxk/cn10k_ethdev.c
index a2e943a3d0..9a072b72a7 100644
--- a/drivers/net/cnxk/cn10k_ethdev.c
+++ b/drivers/net/cnxk/cn10k_ethdev.c
@@ -963,6 +963,7 @@ static const struct rte_pci_id cn10k_pci_nix_map[] = {
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KB, PCI_DEVID_CNXK_RVU_PF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CNF10KB, PCI_DEVID_CNXK_RVU_PF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KA, PCI_DEVID_CNXK_RVU_VF),
+ CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KA, PCI_DEVID_CNXK_RVU_ESWITCH_VF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KAS, PCI_DEVID_CNXK_RVU_VF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CNF10KA, PCI_DEVID_CNXK_RVU_VF),
CNXK_PCI_ID(PCI_SUBSYSTEM_DEVID_CN10KB, PCI_DEVID_CNXK_RVU_VF),
diff --git a/drivers/net/cnxk/cnxk_ethdev.c b/drivers/net/cnxk/cnxk_ethdev.c
index 2372a4e793..ec43de6221 100644
--- a/drivers/net/cnxk/cnxk_ethdev.c
+++ b/drivers/net/cnxk/cnxk_ethdev.c
@@ -390,7 +390,7 @@ nix_update_flow_ctrl_config(struct rte_eth_dev *eth_dev)
struct cnxk_fc_cfg *fc = &dev->fc_cfg;
struct rte_eth_fc_conf fc_cfg = {0};
- if (roc_nix_is_sdp(&dev->nix))
+ if (roc_nix_is_sdp(&dev->nix) || roc_nix_is_esw(&dev->nix))
return 0;
/* Don't do anything if PFC is enabled */
@@ -1449,12 +1449,14 @@ cnxk_nix_configure(struct rte_eth_dev *eth_dev)
goto cq_fini;
/* Init flow control configuration */
- fc_cfg.type = ROC_NIX_FC_RXCHAN_CFG;
- fc_cfg.rxchan_cfg.enable = true;
- rc = roc_nix_fc_config_set(nix, &fc_cfg);
- if (rc) {
- plt_err("Failed to initialize flow control rc=%d", rc);
- goto cq_fini;
+ if (!roc_nix_is_esw(nix)) {
+ fc_cfg.type = ROC_NIX_FC_RXCHAN_CFG;
+ fc_cfg.rxchan_cfg.enable = true;
+ rc = roc_nix_fc_config_set(nix, &fc_cfg);
+ if (rc) {
+ plt_err("Failed to initialize flow control rc=%d", rc);
+ goto cq_fini;
+ }
}
/* Update flow control configuration to PMD */
@@ -1976,11 +1978,21 @@ cnxk_eth_dev_init(struct rte_eth_dev *eth_dev)
TAILQ_INIT(&dev->mcs_list);
}
- plt_nix_dbg("Port=%d pf=%d vf=%d ver=%s hwcap=0x%" PRIx64
- " rxoffload_capa=0x%" PRIx64 " txoffload_capa=0x%" PRIx64,
- eth_dev->data->port_id, roc_nix_get_pf(nix),
- roc_nix_get_vf(nix), CNXK_ETH_DEV_PMD_VERSION, dev->hwcap,
- dev->rx_offload_capa, dev->tx_offload_capa);
+ /* Reserve a switch domain for eswitch device */
+ if (pci_dev->id.device_id == PCI_DEVID_CNXK_RVU_ESWITCH_VF) {
+ eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
+ rc = rte_eth_switch_domain_alloc(&dev->switch_domain_id);
+ if (rc) {
+ plt_err("Failed to alloc switch domain: %d", rc);
+ goto free_mac_addrs;
+ }
+ }
+
+ plt_nix_dbg("Port=%d pf=%d vf=%d ver=%s hwcap=0x%" PRIx64 "
rxoffload_capa=0x%" PRIx64
+ " txoffload_capa=0x%" PRIx64,
+ eth_dev->data->port_id, roc_nix_get_pf(nix),
roc_nix_get_vf(nix),
+ CNXK_ETH_DEV_PMD_VERSION, dev->hwcap, dev->rx_offload_capa,
+ dev->tx_offload_capa);
return 0;
free_mac_addrs:
@@ -2046,6 +2058,11 @@ cnxk_eth_dev_uninit(struct rte_eth_dev *eth_dev, bool
reset)
}
}
+ /* Free switch domain ID reserved for eswitch device */
+ if ((eth_dev->data->dev_flags & RTE_ETH_DEV_REPRESENTOR) &&
+ rte_eth_switch_domain_free(dev->switch_domain_id))
+ plt_err("Failed to free switch domain");
+
/* Disable and free rte_meter entries */
nix_meter_fini(dev);
diff --git a/drivers/net/cnxk/cnxk_ethdev.h b/drivers/net/cnxk/cnxk_ethdev.h
index 4d3ebf123b..d8eba5e1dd 100644
--- a/drivers/net/cnxk/cnxk_ethdev.h
+++ b/drivers/net/cnxk/cnxk_ethdev.h
@@ -424,6 +424,9 @@ struct cnxk_eth_dev {
/* MCS device */
struct cnxk_mcs_dev *mcs_dev;
struct cnxk_macsec_sess_list mcs_list;
+
+ /* Eswitch domain ID */
+ uint16_t switch_domain_id;
};
struct cnxk_eth_rxq_sp {
diff --git a/drivers/net/cnxk/cnxk_ethdev_ops.c
b/drivers/net/cnxk/cnxk_ethdev_ops.c
index 5de2919047..67fbf7c269 100644
--- a/drivers/net/cnxk/cnxk_ethdev_ops.c
+++ b/drivers/net/cnxk/cnxk_ethdev_ops.c
@@ -71,6 +71,10 @@ cnxk_n
[PATCH v3 18/23] common/cnxk: support port representor and represented port
From: Kiran Kumar K
Implementing the common infrastructural changes for supporting port
representors and represented ports used as action and pattern in net
layer.
Signed-off-by: Kiran Kumar K
Signed-off-by: Satheesh Paul
Signed-off-by: Harman Kalra
---
drivers/common/cnxk/roc_npc.c | 63 +++--
drivers/common/cnxk/roc_npc.h | 13 +-
drivers/common/cnxk/roc_npc_mcam.c | 62 +++-
drivers/common/cnxk/roc_npc_parse.c | 28 -
drivers/common/cnxk/roc_npc_priv.h | 2 +
drivers/net/cnxk/cnxk_flow.c| 2 +-
6 files changed, 125 insertions(+), 45 deletions(-)
diff --git a/drivers/common/cnxk/roc_npc.c b/drivers/common/cnxk/roc_npc.c
index 67a660a2bc..f4fb8c7660 100644
--- a/drivers/common/cnxk/roc_npc.c
+++ b/drivers/common/cnxk/roc_npc.c
@@ -570,6 +570,8 @@ npc_parse_actions(struct roc_npc *roc_npc, const struct
roc_npc_attr *attr,
flow->ctr_id = NPC_COUNTER_NONE;
flow->mtr_id = ROC_NIX_MTR_ID_INVALID;
pf_func = npc->pf_func;
+ if (flow->has_rep)
+ pf_func = flow->rep_pf_func;
for (; actions->type != ROC_NPC_ACTION_TYPE_END; actions++) {
switch (actions->type) {
@@ -898,10 +900,14 @@ npc_parse_pattern(struct npc *npc, const struct
roc_npc_item_info pattern[],
struct roc_npc_flow *flow, struct npc_parse_state *pst)
{
npc_parse_stage_func_t parse_stage_funcs[] = {
- npc_parse_meta_items, npc_parse_mark_item, npc_parse_pre_l2,
npc_parse_cpt_hdr,
- npc_parse_higig2_hdr, npc_parse_tx_queue, npc_parse_la,
npc_parse_lb,
- npc_parse_lc, npc_parse_ld,npc_parse_le,
npc_parse_lf,
- npc_parse_lg, npc_parse_lh,
+ npc_parse_meta_items, npc_parse_port_representor_id,
+ npc_parse_mark_item, npc_parse_pre_l2,
+ npc_parse_cpt_hdr,npc_parse_higig2_hdr,
+ npc_parse_tx_queue, npc_parse_la,
+ npc_parse_lb, npc_parse_lc,
+ npc_parse_ld, npc_parse_le,
+ npc_parse_lf, npc_parse_lg,
+ npc_parse_lh,
};
uint8_t layer = 0;
int key_offset;
@@ -1140,15 +1146,20 @@ npc_rss_action_program(struct roc_npc *roc_npc,
struct roc_npc_flow *flow)
{
const struct roc_npc_action_rss *rss;
+ struct roc_npc *npc = roc_npc;
uint32_t rss_grp;
uint8_t alg_idx;
int rc;
+ if (flow->has_rep) {
+ npc = roc_npc->rep_npc;
+ npc->flowkey_cfg_state = roc_npc->flowkey_cfg_state;
+ }
+
for (; actions->type != ROC_NPC_ACTION_TYPE_END; actions++) {
if (actions->type == ROC_NPC_ACTION_TYPE_RSS) {
rss = (const struct roc_npc_action_rss *)actions->conf;
- rc = npc_rss_action_configure(roc_npc, rss, &alg_idx,
- &rss_grp, flow->mcam_id);
+ rc = npc_rss_action_configure(npc, rss, &alg_idx,
&rss_grp, flow->mcam_id);
if (rc)
return rc;
@@ -1171,7 +1182,7 @@ npc_vtag_cfg_delete(struct roc_npc *roc_npc, struct
roc_npc_flow *flow)
struct roc_nix *roc_nix = roc_npc->roc_nix;
struct nix_vtag_config *vtag_cfg;
struct nix_vtag_config_rsp *rsp;
- struct mbox *mbox;
+ struct mbox *mbox, *ombox;
struct nix *nix;
int rc = 0;
@@ -1181,7 +1192,10 @@ npc_vtag_cfg_delete(struct roc_npc *roc_npc, struct
roc_npc_flow *flow)
} tx_vtag_action;
nix = roc_nix_to_nix_priv(roc_nix);
- mbox = mbox_get((&nix->dev)->mbox);
+ ombox = (&nix->dev)->mbox;
+ if (flow->has_rep)
+ ombox = flow->rep_mbox;
+ mbox = mbox_get(ombox);
tx_vtag_action.reg = flow->vtag_action;
vtag_cfg = mbox_alloc_msg_nix_vtag_cfg(mbox);
@@ -1400,6 +1414,7 @@ npc_vtag_strip_action_configure(struct mbox *mbox,
rx_vtag_action |= (NIX_RX_VTAGACTION_VTAG_VALID << 15);
rx_vtag_action |= ((uint64_t)NPC_LID_LB << 8);
+ rx_vtag_action |= ((uint64_t)NIX_RX_VTAG_TYPE6 << 12);
rx_vtag_action |= NIX_RX_VTAGACTION_VTAG0_RELPTR;
if (*strip_cnt == 2) {
@@ -1432,6 +1447,8 @@ npc_vtag_action_program(struct roc_npc *roc_npc,
nix = roc_nix_to_nix_priv(roc_nix);
mbox = (&nix->dev)->mbox;
+ if (flow->has_rep)
+ mbox = flow->rep_mbox;
memset(vlan_info, 0, sizeof(vlan_info));
@@ -1448,6 +1465,7 @@ npc_vtag_action_program(struct roc_npc *roc_npc,
if (rc)
return rc;
+ plt_npc_dbg("VLAN strip action, strip_cnt %d",
strip_cnt);
if (strip_cnt == 2)
actions++;
@@ -15
[PATCH v3 19/23] net/cnxk: add represented port pattern and action
From: Kiran Kumar K
Adding support for represented_port item matching and action.
Signed-off-by: Kiran Kumar K
Signed-off-by: Satheesh Paul
Signed-off-by: Harman Kalra
---
doc/guides/nics/cnxk.rst | 1 +
doc/guides/nics/features/cnxk.ini | 1 +
doc/guides/nics/features/cnxk_vec.ini | 2 +
doc/guides/nics/features/cnxk_vf.ini | 2 +
drivers/net/cnxk/cnxk_flow.c | 107 ++
5 files changed, 63 insertions(+), 50 deletions(-)
diff --git a/doc/guides/nics/cnxk.rst b/doc/guides/nics/cnxk.rst
index 496474913f..0f80d65562 100644
--- a/doc/guides/nics/cnxk.rst
+++ b/doc/guides/nics/cnxk.rst
@@ -38,6 +38,7 @@ Features of the CNXK Ethdev PMD are:
- Ingress meter support
- Queue based priority flow control support
- Port representors
+- Represented port pattern matching and action
Prerequisites
-
diff --git a/doc/guides/nics/features/cnxk.ini
b/doc/guides/nics/features/cnxk.ini
index 94e7a6ab8d..8957eba46b 100644
--- a/doc/guides/nics/features/cnxk.ini
+++ b/doc/guides/nics/features/cnxk.ini
@@ -73,6 +73,7 @@ mpls = Y
nvgre= Y
pppoes = Y
raw = Y
+represented_port = Y
sctp = Y
tcp = Y
tx_queue = Y
diff --git a/doc/guides/nics/features/cnxk_vec.ini
b/doc/guides/nics/features/cnxk_vec.ini
index 6086b3d73f..193fd14fbb 100644
--- a/doc/guides/nics/features/cnxk_vec.ini
+++ b/doc/guides/nics/features/cnxk_vec.ini
@@ -67,6 +67,7 @@ mpls = Y
nvgre= Y
pppoes = Y
raw = Y
+represented_port = Y
sctp = Y
tcp = Y
tx_queue = Y
@@ -86,6 +87,7 @@ of_set_vlan_pcp = Y
of_set_vlan_vid = Y
pf = Y
queue= Y
+represented_port = Y
rss = Y
security = Y
vf = Y
diff --git a/doc/guides/nics/features/cnxk_vf.ini
b/doc/guides/nics/features/cnxk_vf.ini
index 53aa2a3d0c..7ae49b8107 100644
--- a/doc/guides/nics/features/cnxk_vf.ini
+++ b/doc/guides/nics/features/cnxk_vf.ini
@@ -64,6 +64,7 @@ mpls = Y
nvgre= Y
pppoes = Y
raw = Y
+represented_port = Y
sctp = Y
tcp = Y
tx_queue = Y
@@ -85,6 +86,7 @@ of_set_vlan_pcp = Y
of_set_vlan_vid = Y
pf = Y
queue= Y
+represented_port = Y
rss = Y
security = Y
skip_cman= Y
diff --git a/drivers/net/cnxk/cnxk_flow.c b/drivers/net/cnxk/cnxk_flow.c
index 5f74c356b1..a3b21f761f 100644
--- a/drivers/net/cnxk/cnxk_flow.c
+++ b/drivers/net/cnxk/cnxk_flow.c
@@ -4,67 +4,48 @@
#include
const struct cnxk_rte_flow_term_info term[] = {
- [RTE_FLOW_ITEM_TYPE_ETH] = {ROC_NPC_ITEM_TYPE_ETH,
- sizeof(struct rte_flow_item_eth)},
- [RTE_FLOW_ITEM_TYPE_VLAN] = {ROC_NPC_ITEM_TYPE_VLAN,
-sizeof(struct rte_flow_item_vlan)},
- [RTE_FLOW_ITEM_TYPE_E_TAG] = {ROC_NPC_ITEM_TYPE_E_TAG,
- sizeof(struct rte_flow_item_e_tag)},
- [RTE_FLOW_ITEM_TYPE_IPV4] = {ROC_NPC_ITEM_TYPE_IPV4,
-sizeof(struct rte_flow_item_ipv4)},
- [RTE_FLOW_ITEM_TYPE_IPV6] = {ROC_NPC_ITEM_TYPE_IPV6,
-sizeof(struct rte_flow_item_ipv6)},
- [RTE_FLOW_ITEM_TYPE_IPV6_FRAG_EXT] = {
- ROC_NPC_ITEM_TYPE_IPV6_FRAG_EXT,
- sizeof(struct rte_flow_item_ipv6_frag_ext)},
- [RTE_FLOW_ITEM_TYPE_ARP_ETH_IPV4] = {
- ROC_NPC_ITEM_TYPE_ARP_ETH_IPV4,
- sizeof(struct rte_flow_item_arp_eth_ipv4)},
- [RTE_FLOW_ITEM_TYPE_MPLS] = {ROC_NPC_ITEM_TYPE_MPLS,
-sizeof(struct rte_flow_item_mpls)},
- [RTE_FLOW_ITEM_TYPE_ICMP] = {ROC_NPC_ITEM_TYPE_ICMP,
-sizeof(struct rte_flow_item_icmp)},
- [RTE_FLOW_ITEM_TYPE_UDP] = {ROC_NPC_ITEM_TYPE_UDP,
- sizeof(struct rte_flow_item_udp)},
- [RTE_FLOW_ITEM_TYPE_TCP] = {ROC_NPC_ITEM_TYPE_TCP,
- sizeof(struct rte_flow_item_tcp)},
- [RTE_FLOW_ITEM_TYPE_SCTP] = {ROC_NPC_ITEM_TYPE_SCTP,
-sizeof(struct rte_flow_item_sctp)},
- [RTE_FLOW_ITEM_TYPE_ESP] = {ROC_NPC_ITEM_TYPE_ESP,
- sizeof(struct rte_flow_item_esp)},
- [RTE_FLOW_ITEM_TYPE_GRE] = {ROC_NPC_ITEM_TYPE_GRE,
- sizeof(struct rte_flow_item_gre)},
- [RTE_FLOW_ITEM_TYPE_NVGRE] = {ROC_NPC_ITEM_TYPE_NVGRE,
- sizeof(struct rte_flow_item_nvgre)},
- [RTE_FLOW_ITEM_TYPE_VXLAN]
[PATCH v3 20/23] net/cnxk: add representor port pattern and action
Adding support for representor port as item matching and action.
Signed-off-by: Harman Kalra
---
doc/guides/nics/cnxk.rst | 1 +
doc/guides/nics/features/cnxk.ini | 4 +
doc/guides/nics/features/cnxk_vec.ini | 4 +
doc/guides/nics/features/cnxk_vf.ini | 4 +
drivers/net/cnxk/cnxk_flow.c | 219 +++---
drivers/net/cnxk/cnxk_rep.h | 14 ++
6 files changed, 220 insertions(+), 26 deletions(-)
diff --git a/doc/guides/nics/cnxk.rst b/doc/guides/nics/cnxk.rst
index 0f80d65562..f0d5418581 100644
--- a/doc/guides/nics/cnxk.rst
+++ b/doc/guides/nics/cnxk.rst
@@ -39,6 +39,7 @@ Features of the CNXK Ethdev PMD are:
- Queue based priority flow control support
- Port representors
- Represented port pattern matching and action
+- Port representor pattern matching and action
Prerequisites
-
diff --git a/doc/guides/nics/features/cnxk.ini
b/doc/guides/nics/features/cnxk.ini
index 8957eba46b..b5d9f7e579 100644
--- a/doc/guides/nics/features/cnxk.ini
+++ b/doc/guides/nics/features/cnxk.ini
@@ -71,6 +71,7 @@ ipv6_routing_ext = Y
mark = Y
mpls = Y
nvgre= Y
+port_representor = Y
pppoes = Y
raw = Y
represented_port = Y
@@ -95,6 +96,7 @@ of_set_vlan_pcp = Y
of_set_vlan_vid = Y
pf = Y
port_id = Y
+port_representor = Y
queue= Y
represented_port = Y
rss = Y
@@ -102,3 +104,5 @@ sample = Y
security = Y
skip_cman= Y
vf = Y
+vxlan_decap = I
+vxlan_encap = I
diff --git a/doc/guides/nics/features/cnxk_vec.ini
b/doc/guides/nics/features/cnxk_vec.ini
index 193fd14fbb..92a486664f 100644
--- a/doc/guides/nics/features/cnxk_vec.ini
+++ b/doc/guides/nics/features/cnxk_vec.ini
@@ -65,6 +65,7 @@ ipv6_frag_ext= Y
mark = Y
mpls = Y
nvgre= Y
+port_representor = Y
pppoes = Y
raw = Y
represented_port = Y
@@ -86,8 +87,11 @@ of_push_vlan = Y
of_set_vlan_pcp = Y
of_set_vlan_vid = Y
pf = Y
+port_representor = Y
queue= Y
represented_port = Y
rss = Y
security = Y
vf = Y
+vxlan_decap = I
+vxlan_encap = I
diff --git a/doc/guides/nics/features/cnxk_vf.ini
b/doc/guides/nics/features/cnxk_vf.ini
index 7ae49b8107..a55f0e7ce5 100644
--- a/doc/guides/nics/features/cnxk_vf.ini
+++ b/doc/guides/nics/features/cnxk_vf.ini
@@ -62,6 +62,7 @@ ipv6_routing_ext = Y
mark = Y
mpls = Y
nvgre= Y
+port_representor = Y
pppoes = Y
raw = Y
represented_port = Y
@@ -85,9 +86,12 @@ of_push_vlan = Y
of_set_vlan_pcp = Y
of_set_vlan_vid = Y
pf = Y
+port_representor = Y
queue= Y
represented_port = Y
rss = Y
security = Y
skip_cman= Y
vf = Y
+vxlan_decap = I
+vxlan_encap = I
diff --git a/drivers/net/cnxk/cnxk_flow.c b/drivers/net/cnxk/cnxk_flow.c
index a3b21f761f..261915d84e 100644
--- a/drivers/net/cnxk/cnxk_flow.c
+++ b/drivers/net/cnxk/cnxk_flow.c
@@ -2,6 +2,7 @@
* Copyright(C) 2021 Marvell.
*/
#include
+#include
const struct cnxk_rte_flow_term_info term[] = {
[RTE_FLOW_ITEM_TYPE_ETH] = {ROC_NPC_ITEM_TYPE_ETH, sizeof(struct
rte_flow_item_eth)},
@@ -185,11 +186,44 @@ roc_npc_parse_sample_subaction(struct rte_eth_dev
*eth_dev, const struct rte_flo
return 0;
}
+static int
+representor_portid_action(struct roc_npc_action *in_actions, struct
rte_eth_dev *portid_eth_dev,
+ uint16_t *dst_pf_func, uint8_t has_tunnel_pattern,
int *act_cnt)
+{
+ struct rte_eth_dev *rep_eth_dev = portid_eth_dev;
+ struct rte_flow_action_mark *act_mark;
+ struct cnxk_rep_dev *rep_dev;
+ /* For inserting an action in the list */
+ int i = *act_cnt;
+
+ rep_dev = cnxk_rep_pmd_priv(rep_eth_dev);
+ *dst_pf_func = rep_dev->hw_func;
+
+ /* Add Mark action */
+ i++;
+ act_mark = plt_zmalloc(sizeof(struct rte_flow_action_mark), 0);
+ if (!act_mark) {
+ plt_err("Error allocation memory");
+ return -ENOMEM;
+ }
+
+ /* Mark ID format: (tunnel type - VxLAN, Geneve << 6) | Tunnel decap */
+ act_mark->id = has_tunnel_pattern ? ((has_tunnel_pattern << 6) | 5) : 1;
+ in_actions[i].type = ROC_NPC_ACTION_TYPE_MARK;
+ in_actions[i].conf = (struct rte_flow_action_mark *)act_mark;
+
+ *act_cnt = i;
+ plt_rep_dbg("Rep port %d ID %d mark ID is %d rep_dev->hw_func 0x%x",
rep_dev->port_id,
+ rep_dev->rep_id, act_mark->id
[PATCH v3 21/23] net/cnxk: generalise flow operation APIs
Flow operations can be performed on cnxk ports as well as representor
ports. Since representor ports are not cnxk ports but have eswitch as
base device underneath, special handling is required to align with base
infra. Introducing a flag to generic flow APIs to discriminate if the
operation request made on normal or representor ports.
Signed-off-by: Harman Kalra
---
drivers/net/cnxk/cnxk_flow.c | 270 ++-
drivers/net/cnxk/cnxk_flow.h | 18 +++
2 files changed, 218 insertions(+), 70 deletions(-)
diff --git a/drivers/net/cnxk/cnxk_flow.c b/drivers/net/cnxk/cnxk_flow.c
index 261915d84e..ff89004cc0 100644
--- a/drivers/net/cnxk/cnxk_flow.c
+++ b/drivers/net/cnxk/cnxk_flow.c
@@ -223,7 +223,7 @@ static int
cnxk_map_actions(struct rte_eth_dev *eth_dev, const struct rte_flow_attr *attr,
const struct rte_flow_action actions[], struct roc_npc_action
in_actions[],
struct roc_npc_action_sample *in_sample_actions, uint32_t
*flowkey_cfg,
-uint16_t *dst_pf_func, uint8_t has_tunnel_pattern)
+uint16_t *dst_pf_func, uint8_t has_tunnel_pattern, bool is_rep)
{
struct cnxk_eth_dev *dev = cnxk_eth_pmd_priv(eth_dev);
const struct rte_flow_action_queue *act_q = NULL;
@@ -274,15 +274,18 @@ cnxk_map_actions(struct rte_eth_dev *eth_dev, const
struct rte_flow_attr *attr,
case RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT:
case RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR:
case RTE_FLOW_ACTION_TYPE_PORT_ID:
+ /* No port ID action on representor ethdevs */
+ if (is_rep)
+ continue;
in_actions[i].type = ROC_NPC_ACTION_TYPE_PORT_ID;
in_actions[i].conf = actions->conf;
- act_ethdev = (const struct rte_flow_action_ethdev *)
- actions->conf;
- port_act = (const struct rte_flow_action_port_id *)
- actions->conf;
+ act_ethdev = (const struct rte_flow_action_ethdev
*)actions->conf;
+ port_act = (const struct rte_flow_action_port_id
*)actions->conf;
if (rte_eth_dev_get_name_by_port(
- actions->type != RTE_FLOW_ACTION_TYPE_PORT_ID ?
- act_ethdev->port_id : port_act->id, if_name)) {
+ actions->type !=
RTE_FLOW_ACTION_TYPE_PORT_ID ?
+ act_ethdev->port_id :
+ port_act->id,
+ if_name)) {
plt_err("Name not found for output port id");
goto err_exit;
}
@@ -321,6 +324,9 @@ cnxk_map_actions(struct rte_eth_dev *eth_dev, const struct
rte_flow_attr *attr,
break;
case RTE_FLOW_ACTION_TYPE_RSS:
+ /* No RSS action on representor ethdevs */
+ if (is_rep)
+ continue;
rc = npc_rss_action_validate(eth_dev, attr, actions);
if (rc)
goto err_exit;
@@ -397,22 +403,37 @@ cnxk_map_actions(struct rte_eth_dev *eth_dev, const
struct rte_flow_attr *attr,
static int
cnxk_map_pattern(struct rte_eth_dev *eth_dev, const struct rte_flow_item
pattern[],
-struct roc_npc_item_info in_pattern[], uint8_t
*has_tunnel_pattern)
+struct roc_npc_item_info in_pattern[], uint8_t
*has_tunnel_pattern, bool is_rep)
{
- struct cnxk_eth_dev *dev = cnxk_eth_pmd_priv(eth_dev);
const struct rte_flow_item_ethdev *rep_eth_dev;
struct rte_eth_dev *portid_eth_dev;
char if_name[RTE_ETH_NAME_MAX_LEN];
struct cnxk_eth_dev *hw_dst;
+ struct cnxk_rep_dev *rdev;
+ struct cnxk_eth_dev *dev;
+ struct roc_npc *npc;
int i = 0;
+ if (!is_rep) {
+ dev = cnxk_eth_pmd_priv(eth_dev);
+ npc = &dev->npc;
+ } else {
+ rdev = cnxk_rep_pmd_priv(eth_dev);
+ npc = &rdev->parent_dev->npc;
+
+ npc->rep_npc = npc;
+ npc->rep_port_id = rdev->port_id;
+ npc->rep_pf_func = rdev->hw_func;
+ }
+
while (pattern->type != RTE_FLOW_ITEM_TYPE_END) {
in_pattern[i].spec = pattern->spec;
in_pattern[i].last = pattern->last;
in_pattern[i].mask = pattern->mask;
in_pattern[i].type = term[pattern->type].item_type;
in_pattern[i].size = term[pattern->type].item_size;
- if (pattern->type == RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT) {
+ if (pattern->type == RTE_FLOW_ITEM_TYP
[PATCH v3 22/23] net/cnxk: flow create on representor ports
Implementing base infra for handling flow operations performed on
representor ports, where these representor ports may be representing
native representees or part of companian apps. Also added support for
handling flow create operation
Signed-off-by: Harman Kalra
---
drivers/net/cnxk/cnxk_flow.h | 9 +-
drivers/net/cnxk/cnxk_rep.h | 3 +
drivers/net/cnxk/cnxk_rep_flow.c | 401 +++
drivers/net/cnxk/cnxk_rep_msg.h | 27 +++
drivers/net/cnxk/cnxk_rep_ops.c | 3 +-
drivers/net/cnxk/meson.build | 1 +
6 files changed, 441 insertions(+), 3 deletions(-)
create mode 100644 drivers/net/cnxk/cnxk_rep_flow.c
diff --git a/drivers/net/cnxk/cnxk_flow.h b/drivers/net/cnxk/cnxk_flow.h
index 226694fbed..e51d04b2c9 100644
--- a/drivers/net/cnxk/cnxk_flow.h
+++ b/drivers/net/cnxk/cnxk_flow.h
@@ -16,8 +16,13 @@ struct cnxk_rte_flow_term_info {
uint16_t item_size;
};
-struct roc_npc_flow *cnxk_flow_create(struct rte_eth_dev *dev,
- const struct rte_flow_attr *attr,
+struct cnxk_rte_flow_action_info {
+ uint16_t conf_size;
+};
+
+extern const struct cnxk_rte_flow_term_info term[];
+
+struct roc_npc_flow *cnxk_flow_create(struct rte_eth_dev *dev, const struct
rte_flow_attr *attr,
const struct rte_flow_item pattern[],
const struct rte_flow_action actions[],
struct rte_flow_error *error);
diff --git a/drivers/net/cnxk/cnxk_rep.h b/drivers/net/cnxk/cnxk_rep.h
index b0cf3340a2..1b46e202a8 100644
--- a/drivers/net/cnxk/cnxk_rep.h
+++ b/drivers/net/cnxk/cnxk_rep.h
@@ -20,6 +20,9 @@
/* Common ethdev ops */
extern struct eth_dev_ops cnxk_rep_dev_ops;
+/* Flow ops for representor ports */
+extern struct rte_flow_ops cnxk_rep_flow_ops;
+
struct cnxk_rep_queue_stats {
uint64_t pkts;
uint64_t bytes;
diff --git a/drivers/net/cnxk/cnxk_rep_flow.c b/drivers/net/cnxk/cnxk_rep_flow.c
new file mode 100644
index 00..2613be5b9e
--- /dev/null
+++ b/drivers/net/cnxk/cnxk_rep_flow.c
@@ -0,0 +1,401 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2024 Marvell.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+
+#define DEFAULT_DUMP_FILE_NAME "/tmp/fdump"
+#define MAX_BUFFER_SIZE 1500
+
+const struct cnxk_rte_flow_action_info action_info[] = {
+ [RTE_FLOW_ACTION_TYPE_MARK] = {sizeof(struct rte_flow_action_mark)},
+ [RTE_FLOW_ACTION_TYPE_VF] = {sizeof(struct rte_flow_action_vf)},
+ [RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT] = {sizeof(struct
rte_flow_action_port_id)},
+ [RTE_FLOW_ACTION_TYPE_PORT_ID] = {sizeof(struct
rte_flow_action_port_id)},
+ [RTE_FLOW_ACTION_TYPE_QUEUE] = {sizeof(struct rte_flow_action_queue)},
+ [RTE_FLOW_ACTION_TYPE_RSS] = {sizeof(struct rte_flow_action_rss)},
+ [RTE_FLOW_ACTION_TYPE_SECURITY] = {sizeof(struct
rte_flow_action_security)},
+ [RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID] = {sizeof(struct
rte_flow_action_of_set_vlan_vid)},
+ [RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN] = {sizeof(struct
rte_flow_action_of_push_vlan)},
+ [RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP] = {sizeof(struct
rte_flow_action_of_set_vlan_pcp)},
+ [RTE_FLOW_ACTION_TYPE_METER] = {sizeof(struct rte_flow_action_meter)},
+ [RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP] = {sizeof(struct
rte_flow_action_vxlan_encap)},
+ [RTE_FLOW_ACTION_TYPE_COUNT] = {sizeof(struct rte_flow_action_count)},
+};
+
+static void
+cnxk_flow_params_count(const struct rte_flow_item pattern[], const struct
rte_flow_action actions[],
+ uint16_t *n_pattern, uint16_t *n_action)
+{
+ int i = 0;
+
+ for (; pattern->type != RTE_FLOW_ITEM_TYPE_END; pattern++)
+ i++;
+
+ *n_pattern = ++i;
+ plt_rep_dbg("Total patterns is %d", *n_pattern);
+
+ i = 0;
+ for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++)
+ i++;
+ *n_action = ++i;
+ plt_rep_dbg("Total actions is %d", *n_action);
+}
+
+static void
+populate_attr_data(void *buffer, uint32_t *length, const struct rte_flow_attr
*attr)
+{
+ uint32_t sz = sizeof(struct rte_flow_attr);
+ uint32_t len;
+
+ cnxk_rep_msg_populate_type(buffer, length, CNXK_TYPE_ATTR, sz);
+
+ len = *length;
+ /* Populate the attribute data */
+ rte_memcpy(RTE_PTR_ADD(buffer, len), attr, sz);
+ len += sz;
+
+ *length = len;
+}
+
+static uint16_t
+prepare_pattern_data(const struct rte_flow_item *pattern, uint16_t nb_pattern,
+uint64_t *pattern_data)
+{
+ cnxk_pattern_hdr_t hdr;
+ uint16_t len = 0;
+ int i = 0;
+
+ for (i = 0; i < nb_pattern; i++) {
+ /* Populate the pattern type hdr */
+ memset(&hdr, 0, sizeof(cnxk_pattern_hdr_t));
+ hdr.type = pattern->type;
+ if (pattern->spec) {
+
[PATCH v3 23/23] net/cnxk: other flow operations
Implementing other flow operations - validate, destroy, query,
flush, dump for representor ports
Signed-off-by: Harman Kalra
---
drivers/net/cnxk/cnxk_rep_flow.c | 414 +++
drivers/net/cnxk/cnxk_rep_msg.h | 32 +++
2 files changed, 446 insertions(+)
diff --git a/drivers/net/cnxk/cnxk_rep_flow.c b/drivers/net/cnxk/cnxk_rep_flow.c
index 2613be5b9e..d26f5aa12c 100644
--- a/drivers/net/cnxk/cnxk_rep_flow.c
+++ b/drivers/net/cnxk/cnxk_rep_flow.c
@@ -267,6 +267,222 @@ populate_action_data(void *buffer, uint32_t *length,
const struct rte_flow_actio
*length = len;
}
+static int
+process_flow_destroy(struct cnxk_rep_dev *rep_dev, void *flow,
cnxk_rep_msg_ack_data_t *adata)
+{
+ cnxk_rep_msg_flow_destroy_meta_t msg_fd_meta;
+ uint32_t len = 0, rc;
+ void *buffer;
+ size_t size;
+
+ /* If representor not representing any active VF, return 0 */
+ if (!rep_dev->is_vf_active)
+ return 0;
+
+ size = MAX_BUFFER_SIZE;
+ buffer = plt_zmalloc(size, 0);
+ if (!buffer) {
+ plt_err("Failed to allocate mem");
+ rc = -ENOMEM;
+ goto fail;
+ }
+
+ cnxk_rep_msg_populate_header(buffer, &len);
+
+ msg_fd_meta.portid = rep_dev->rep_id;
+ msg_fd_meta.flow = (uint64_t)flow;
+ plt_rep_dbg("Flow Destroy: flow 0x%" PRIu64 ", portid %d",
msg_fd_meta.flow,
+ msg_fd_meta.portid);
+ cnxk_rep_msg_populate_command_meta(buffer, &len, &msg_fd_meta,
+
sizeof(cnxk_rep_msg_flow_destroy_meta_t),
+ CNXK_REP_MSG_FLOW_DESTROY);
+ cnxk_rep_msg_populate_msg_end(buffer, &len);
+
+ rc = cnxk_rep_msg_send_process(rep_dev, buffer, len, adata);
+ if (rc) {
+ plt_err("Failed to process the message, err %d", rc);
+ goto fail;
+ }
+
+ return 0;
+fail:
+ return rc;
+}
+
+static int
+copy_flow_dump_file(FILE *target)
+{
+ FILE *source = NULL;
+ int pos;
+ char ch;
+
+ source = fopen(DEFAULT_DUMP_FILE_NAME, "r");
+ if (source == NULL) {
+ plt_err("Failed to read default dump file: %s, err %d",
DEFAULT_DUMP_FILE_NAME,
+ errno);
+ return errno;
+ }
+
+ fseek(source, 0L, SEEK_END);
+ pos = ftell(source);
+ fseek(source, 0L, SEEK_SET);
+ while (pos--) {
+ ch = fgetc(source);
+ fputc(ch, target);
+ }
+
+ fclose(source);
+
+ /* Remove the default file after reading */
+ remove(DEFAULT_DUMP_FILE_NAME);
+
+ return 0;
+}
+
+static int
+process_flow_dump(struct cnxk_rep_dev *rep_dev, struct rte_flow *flow, FILE
*file,
+ cnxk_rep_msg_ack_data_t *adata)
+{
+ cnxk_rep_msg_flow_dump_meta_t msg_fp_meta;
+ uint32_t len = 0, rc;
+ void *buffer;
+ size_t size;
+
+ size = MAX_BUFFER_SIZE;
+ buffer = plt_zmalloc(size, 0);
+ if (!buffer) {
+ plt_err("Failed to allocate mem");
+ rc = -ENOMEM;
+ goto fail;
+ }
+
+ cnxk_rep_msg_populate_header(buffer, &len);
+
+ msg_fp_meta.portid = rep_dev->rep_id;
+ msg_fp_meta.flow = (uint64_t)flow;
+ msg_fp_meta.is_stdout = (file == stdout) ? 1 : 0;
+
+ plt_rep_dbg("Flow Dump: flow 0x%" PRIu64 ", portid %d stdout %d",
msg_fp_meta.flow,
+ msg_fp_meta.portid, msg_fp_meta.is_stdout);
+ cnxk_rep_msg_populate_command_meta(buffer, &len, &msg_fp_meta,
+
sizeof(cnxk_rep_msg_flow_dump_meta_t),
+ CNXK_REP_MSG_FLOW_DUMP);
+ cnxk_rep_msg_populate_msg_end(buffer, &len);
+
+ rc = cnxk_rep_msg_send_process(rep_dev, buffer, len, adata);
+ if (rc) {
+ plt_err("Failed to process the message, err %d", rc);
+ goto fail;
+ }
+
+ /* Copy contents from default file to user file */
+ if (file != stdout)
+ copy_flow_dump_file(file);
+
+ return 0;
+fail:
+ return rc;
+}
+
+static int
+process_flow_flush(struct cnxk_rep_dev *rep_dev, cnxk_rep_msg_ack_data_t
*adata)
+{
+ cnxk_rep_msg_flow_flush_meta_t msg_ff_meta;
+ uint32_t len = 0, rc;
+ void *buffer;
+ size_t size;
+
+ size = MAX_BUFFER_SIZE;
+ buffer = plt_zmalloc(size, 0);
+ if (!buffer) {
+ plt_err("Failed to allocate mem");
+ rc = -ENOMEM;
+ goto fail;
+ }
+
+ cnxk_rep_msg_populate_header(buffer, &len);
+
+ msg_ff_meta.portid = rep_dev->rep_id;
+ plt_rep_dbg("Flow Flush: portid %d", msg_ff_meta.portid);
+ cnxk_rep_msg_populate_command_meta(buffer, &len, &msg_ff_meta,
+
sizeof(cnxk_rep_msg_flow_flush_meta_t),
+
Re: [PATCH] [v3]lib/telemetry:fix telemetry conns leak in case of socket write fail
On Tue, Jan 30, 2024 at 2:57 AM Shaowei Sun <1819846...@qq.com> wrote:
>
> Telemetry can only create 10 conns by default, each of which is processed
> by a thread.
>
> When a thread fails to write using socket, the thread will end directly
> without reducing the total number of conns.
>
> This will result in the machine running for a long time, and if there are
> 10 failures, the telemetry will be unavailable
>
> Fixes: 6dd571fd07c3 ("telemetry: introduce new functionality")
>
> Signed-off-by: Shaowei Sun <1819846...@qq.com>
> Acked-by: Bruce Richardson
> Acked-by: Ciara Power
> Acked-by: Chengwen Feng
Thanks for the fix.
As far as I can see, the limiting of the number of connections (which
here results in a DoS on the telemetry socket) was added in commit
2a7d0b872f79 ("telemetry: add upper limit on connections").
If you confirm this is indeed this commit that introduced the issue, I
will fix the Fixes: tag myself when applying.
--
David Marchand
RE: [PATCH 1/2] app/test-crypto-perf: fix copy segment size calculation
Hi,
I saw other crypto perf fixes are reviewed, any chance to take a look at this
series?
> -Original Message-
> From: Suanming Mou
> Sent: Wednesday, January 3, 2024 12:00 PM
> To: ciara.po...@intel.com
> Cc: dev@dpdk.org
> Subject: [PATCH 1/2] app/test-crypto-perf: fix copy segment size calculation
>
> For the case crypto device requires headroom and tailroom, the segment_sz in
> options also contains the headroom_sz and tailroom_sz, but mbuf's data_len is
> user's segment_sz without headroom_sz and tailroom_sz. That means the data
> size to be copied should use user's segment_sz instead of options->segment_sz.
>
> This commit fixes the copy segment size calculation.
>
> Fixes: 14864c4217ce ("test/crypto-perf: populate mbuf in latency test")
>
> Signed-off-by: Suanming Mou
> ---
> app/test-crypto-perf/cperf_test_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/app/test-crypto-perf/cperf_test_common.c b/app/test-crypto-
> perf/cperf_test_common.c
> index ad2076dd2e..8faf832527 100644
> --- a/app/test-crypto-perf/cperf_test_common.c
> +++ b/app/test-crypto-perf/cperf_test_common.c
> @@ -271,7 +271,7 @@ cperf_mbuf_set(struct rte_mbuf *mbuf,
> const struct cperf_options *options,
> const struct cperf_test_vector *test_vector) {
> - uint32_t segment_sz = options->segment_sz;
> + uint32_t segment_sz = options->segment_sz - options->headroom_sz -
> +options->tailroom_sz;
> uint8_t *mbuf_data;
> uint8_t *test_data;
> uint32_t remaining_bytes = options->max_buffer_size;
> --
> 2.34.1
RE: [EXT] [PATCH 1/3] cryptodev: add ec points to sm2 op
> -Original Message- > From: Akhil Goyal > Sent: Thursday, February 1, 2024 9:08 AM > To: Kusztal, ArkadiuszX ; dev@dpdk.org > Cc: Power, Ciara > Subject: RE: [EXT] [PATCH 1/3] cryptodev: add ec points to sm2 op > > > -- > > In the case when PMD cannot support full process of the SM2, but > > elliptic curve computation only, additional fields are needed to > > handle such a case. > > > > Asym crypto APIs are no longer experimental. > Hence adding new fields would lead to ABI break. It seems that `__rte_crypto_op_reset` `rte_crypto_op_pool_create` functions do not need versioning, and we could easily do it if needed. But the field `flags` changes an offset, and this is actually problematic. Which means that we cannot do this change before 24.11. > > > Points C1, kP therefore were added to the SM2 crypto operation struct. > > > > Signed-off-by: Arkadiusz Kusztal
Re: [PATCH v5 0/5] net/gve: RSS Support for GVE Driver
On 1/31/2024 10:13 PM, Joshua Washington wrote: > This patch series introduces RSS support for the GVE poll-mode driver. > This series includes implementations of the following eth_dev_ops: > > 1) rss_hash_update > 2) rss_hash_conf_get > 3) reta_query > 4) reta_update > > In rss_hash_update, the GVE driver supports the following RSS hash > types: > > * RTE_ETH_RSS_IPV4 > * RTE_ETH_RSS_NONFRAG_IPV4_TCP > * RTE_ETH_RSS_NONFRAG_IPV4_UDP > * RTE_ETH_RSS_IPV6 > * RTE_ETH_RSS_IPV6_EX > * RTE_ETH_RSS_NONFRAG_IPV6_TCP > * RTE_ETH_RSS_NONFRAG_IPV6_UDP > * RTE_ETH_RSS_IPV6_TCP_EX > * RTE_ETH_RSS_IPV6_UDP_EX > > The hash key is 40B, and the lookup table has 128 entries. These values > are not configurable in this implementation. > > In general, the DPDK driver expects the RSS hash configuration to be set > with a key before the redriection table is set up. When the RSS hash is > configured, a default redirection table is generated based on the number > of queues. When the device is re-configured, the redirection table is > reset to the default value based on the queue count. > > An important note is that the gVNIC device expects 32 bit integers for > RSS redirection table entries, while the RTE API uses 16 bit integers. > However, this is unlikely to be an issue, as these values represent > receive queues, and the gVNIC device does not support anywhere near 64K > queues. > > This series also updates the corresponding feature matrix ertries and > documentation as it pertains to RSS support in the GVE driver. > > v2: > Add commmit messages for patches with it missing, and other checkpatches > fixes. > > Note: There is a warning about complex macros being parenthesized that > does not seem to be well-founded. > > v3: > Fix build warnings that come up on certain distros. > > v4: > Fix formatting in gve_adminq.c > > v5: > Update commit messages to comply with check-git-log. > Fold feature matrix and documentation updates into relevant commits. > > Joshua Washington (5): > net/gve: expose RSS offload support in dev info > net/gve: add RSS adminq command > net/gve: add gve RSS library > net/gve: add RSS configuration update support > net/gve: add RSS redirection table update support Series applied to dpdk-next-net/main, thanks.
[PATCH v3] doc: update guideline for fix commit messages
Maintainers remove the Cc author line when merging the patch.
So, the guidelines is updated with a suggestion for the placement
of Cc lines in a commit message for easy merging.
Signed-off-by: Sivaramakrishnan Venkat
---
v3:
- Other samples updated to the desired format for the "Cc:" line in the
commit message
v2:
- Samples updated to the desired format for the "Cc:" line in the commit
message
---
doc/guides/contributing/patches.rst | 12
doc/guides/contributing/stable.rst | 3 ++-
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/doc/guides/contributing/patches.rst
b/doc/guides/contributing/patches.rst
index e286d9e6d5..4e1768025e 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -271,9 +271,10 @@ Here are some guidelines for the body of a commit message:
Update the docs, fixing description of some parameter.
Fixes: abcdefgh1234 ("doc: add some parameter")
- Cc: aut...@example.com
Signed-off-by: Alex Smith
+ ---
+ Cc: aut...@example.com
* When fixing an error or warning it is useful to add the error message and
instructions on how to reproduce it.
@@ -300,9 +301,10 @@ in the body of the commit message. For example::
Coverity issue: 12345
Fixes: abcdefgh1234 ("doc: add some parameter")
- Cc: aut...@example.com
Signed-off-by: Alex Smith
+ ---
+ Cc: aut...@example.com
`Bugzilla `_
@@ -319,9 +321,10 @@ For example::
Bugzilla ID: 12345
Fixes: abcdefgh1234 ("doc: add some parameter")
-Cc: aut...@example.com
Signed-off-by: Alex Smith
+---
+Cc: aut...@example.com
Patch for Stable Releases
~
@@ -336,9 +339,10 @@ In the commit message body the Cc: sta...@dpdk.org should
be inserted as follows
Update the docs, fixing description of some parameter.
Fixes: abcdefgh1234 ("doc: add some parameter")
- Cc: sta...@dpdk.org
Signed-off-by: Alex Smith
+ ---
+ Cc: sta...@dpdk.org
For further information on stable contribution you can go to
:doc:`Stable Contribution Guide `.
diff --git a/doc/guides/contributing/stable.rst
b/doc/guides/contributing/stable.rst
index 8156b72b20..bf7f4bceec 100644
--- a/doc/guides/contributing/stable.rst
+++ b/doc/guides/contributing/stable.rst
@@ -92,9 +92,10 @@ commit message body as follows::
Update the docs, fixing description of some parameter.
Fixes: abcdefgh1234 ("doc: add some parameter")
- Cc: sta...@dpdk.org
Signed-off-by: Alex Smith
+ ---
+ Cc: sta...@dpdk.org
Fixes not suitable for backport should not include the ``Cc: sta...@dpdk.org``
tag.
--
2.25.1
[PATCH v2] app/testpmd: command to get descriptor used count
From: Satha Rao
Existing Rx desc used count command extended to get Tx queue
used count.
testpmd> show port 0 rxq 0 desc used count
testpmd> show port 0 txq 0 desc used count
Signed-off-by: Satha Rao
---
Depends-on: series-30833 ("ethdev: support Tx queue used count")
v2:
extended rx_queue_desc_used_count command to support Tx
updated testpmd_app_ug with new command
app/test-pmd/cmdline.c | 184 +++-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 10 +-
2 files changed, 104 insertions(+), 90 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index f704319771..c8c88f3236 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -12638,6 +12638,104 @@ static cmdline_parse_inst_t
cmd_show_port_supported_ptypes = {
},
};
+/* *** display rx/tx queue descriptor used count *** */
+struct cmd_show_rx_tx_queue_desc_used_count_result {
+ cmdline_fixed_string_t cmd_show;
+ cmdline_fixed_string_t cmd_port;
+ cmdline_fixed_string_t cmd_dir;
+ cmdline_fixed_string_t cmd_desc;
+ cmdline_fixed_string_t cmd_used;
+ cmdline_fixed_string_t cmd_count;
+ portid_t cmd_pid;
+ portid_t cmd_qid;
+};
+
+static void
+cmd_show_rx_tx_queue_desc_used_count_parsed(void *parsed_result, __rte_unused
struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_show_rx_tx_queue_desc_used_count_result *res = parsed_result;
+ int rc;
+
+ if (!strcmp(res->cmd_dir, "rxq")) {
+ if (rte_eth_rx_queue_is_valid(res->cmd_pid, res->cmd_qid) != 0)
{
+ fprintf(stderr, "Invalid input: port id = %d, queue id
= %d\n",
+ res->cmd_pid, res->cmd_qid);
+ return;
+ }
+
+ rc = rte_eth_rx_queue_count(res->cmd_pid, res->cmd_qid);
+ if (rc < 0) {
+ fprintf(stderr, "Invalid queueid = %d\n", res->cmd_qid);
+ return;
+ }
+ printf("RxQ %d used desc count = %d\n", res->cmd_qid, rc);
+ } else if (!strcmp(res->cmd_dir, "txq")) {
+ if (rte_eth_tx_queue_is_valid(res->cmd_pid, res->cmd_qid) != 0)
{
+ fprintf(stderr, "Invalid input: port id = %d, queue id
= %d\n",
+ res->cmd_pid, res->cmd_qid);
+ return;
+ }
+
+ rc = rte_eth_tx_queue_count(res->cmd_pid, res->cmd_qid);
+ if (rc < 0) {
+ fprintf(stderr, "Tx queue count get failed rc=%d
queue_id=%d\n", rc,
+ res->cmd_qid);
+ return;
+ }
+ printf("TxQ %d used desc count = %d\n", res->cmd_qid, rc);
+ }
+}
+
+static cmdline_parse_token_string_t cmd_show_rx_tx_queue_desc_used_count_show =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_tx_queue_desc_used_count_result,
+cmd_show, "show");
+static cmdline_parse_token_string_t cmd_show_rx_tx_queue_desc_used_count_port =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_tx_queue_desc_used_count_result,
+cmd_port, "port");
+static cmdline_parse_token_num_t cmd_show_rx_tx_queue_desc_used_count_pid =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_show_rx_tx_queue_desc_used_count_result,
+cmd_pid, RTE_UINT16);
+static cmdline_parse_token_string_t cmd_show_rx_tx_queue_desc_used_count_dir =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_tx_queue_desc_used_count_result,
+cmd_dir, "rxq#txq");
+static cmdline_parse_token_num_t cmd_show_rx_tx_queue_desc_used_count_qid =
+ TOKEN_NUM_INITIALIZER
+ (struct cmd_show_rx_tx_queue_desc_used_count_result,
+cmd_qid, RTE_UINT16);
+static cmdline_parse_token_string_t cmd_show_rx_tx_queue_desc_used_count_desc =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_tx_queue_desc_used_count_result,
+cmd_desc, "desc");
+static cmdline_parse_token_string_t cmd_show_rx_tx_queue_desc_used_count_used =
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_tx_queue_desc_used_count_result,
+cmd_count, "used");
+static cmdline_parse_token_string_t cmd_show_rx_tx_queue_desc_used_count_count
=
+ TOKEN_STRING_INITIALIZER
+ (struct cmd_show_rx_tx_queue_desc_used_count_result,
+cmd_count, "count");
+static cmdline_parse_inst_t cmd_show_rx_tx_queue_desc_used_count = {
+ .f = cmd_show_rx_tx_queue_desc_used_count_parsed,
+ .data = NULL,
+ .help_str = "show port rxq|txq desc used count",
+ .tokens = {
+ (void *)&cmd_show_rx_tx_queue_desc_used_count_show,
+ (void *)&cmd_show_rx_tx_queue_desc_used_count_port,
?????? [PATCH] [v3]lib/telemetry:fix telemetry conns leak in case of socket write fail
Yes, you are correct, it should be the commit 2a7d0b872f79 that introduced the issue. Thank you for the correction. 1819846...@qq.com -- -- ??: "David Marchand"
Re: [PATCH v2 11/11] eventdev: RFC clarify docs on event object fields
On Thu, Feb 1, 2024 at 3:05 PM Bruce Richardson
wrote:
>
> On Fri, Jan 19, 2024 at 05:43:46PM +, Bruce Richardson wrote:
> > Clarify the meaning of the NEW, FORWARD and RELEASE event types.
> > For the fields in "rte_event" struct, enhance the comments on each to
> > clarify the field's use, and whether it is preserved between enqueue and
> > dequeue, and it's role, if any, in scheduling.
> >
> > Signed-off-by: Bruce Richardson
> > ---
> >
> > As with the previous patch, please review this patch to ensure that the
> > expected semantics of the various event types and event fields have not
> > changed in an unexpected way.
> > ---
> > lib/eventdev/rte_eventdev.h | 105 ++--
> > 1 file changed, 77 insertions(+), 28 deletions(-)
> >
>
>
> > #define RTE_EVENT_OP_RELEASE2
> > /**< Release the flow context associated with the schedule type.
> > *
> > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ATOMIC*
> > + * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_ATOMIC
> > * then this function hints the scheduler that the user has completed
> > critical
> > * section processing in the current atomic context.
> > * The scheduler is now allowed to schedule events from the same flow from
> > @@ -1442,21 +1446,19 @@ struct rte_event_vector {
> > * performance, but the user needs to design carefully the split into
> > critical
> > * vs non-critical sections.
> > *
> > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ORDERED*
> > - * then this function hints the scheduler that the user has done all that
> > need
> > - * to maintain event order in the current ordered context.
> > - * The scheduler is allowed to release the ordered context of this port and
> > - * avoid reordering any following enqueues.
> > - *
> > - * Early ordered context release may increase parallelism and thus system
> > - * performance.
>
> Before I do up a V3 of this patchset, I'd like to try and understand a bit
> more what was meant by the original text for reordered here. The use of
> "context" is very ambiguous, since it could refer to a number of different
> things here.
>
> For me, RELEASE for ordered queues should mean much the same as for atomic
> queues - it means that the event being released is to be "dropped" from the
> point of view of the eventdev scheduler - i.e. any atomic locks held for
> that event should be released, and any reordering slots for it should be
> skipped. However, the text above seems to imply that when we release one
> event it means that we should stop reordering all subsequent events for
> that port - which seems wrong to me. Especially in the case where
> reordering may be done per flow, does one release mean that we need to go
> through all flows and mark as skipped all reordered slots awaiting returned
> events from that port? If this is what is intended, how is it better than
> just doing another dequeue call from the port, which releases everything
> automatically anyway?
>
> Jerin, I believe you were the author of the original text, can you perhaps
> clarify? Other PMD maintainers, can any of you chime in with current
> supported behaviour when enqueuing a release of an ordered event?
If N number of cores does rte_event_dequeue_burst() and got the same
flow, and it is scheduled as
RTE_SCHED_TYPE_ORDERED and then irrespective of the timing downstream
rte_event_enqueue_burst()
invocation any core. Upon rte_event_enqueue_burst() completion, the
events will be enqueued the downstream
queue in the ingress order.
Assume, one of the core, calls RTE_EVENT_OP_RELEASE in between
dequeue and enqueue, then that event no more
eligible for the ingress order maintenance.
> Ideally, I'd like to see this simplified whereby release for ordered
> behaves like that for atomic, and refers to the current event only, (and
> drop any mention of contexts).
>
> Thanks,
> /Bruce
Re: [PATCH] [v3]lib/telemetry:fix telemetry conns leak in case of socket write fail
On Tue, Jan 30, 2024 at 2:57 AM Shaowei Sun <1819846...@qq.com> wrote:
>
> Telemetry can only create 10 conns by default, each of which is processed
> by a thread.
>
> When a thread fails to write using socket, the thread will end directly
> without reducing the total number of conns.
>
> This will result in the machine running for a long time, and if there are
> 10 failures, the telemetry will be unavailable
>
Fixes: 2a7d0b872f79 ("telemetry: add upper limit on connections")
Cc: sta...@dpdk.org
>
> Signed-off-by: Shaowei Sun <1819846...@qq.com>
> Acked-by: Bruce Richardson
> Acked-by: Ciara Power
> Acked-by: Chengwen Feng
Applied, thanks for the fix!
--
David Marchand
Re: [PATCH v2 11/11] eventdev: RFC clarify docs on event object fields
On Thu, Feb 01, 2024 at 08:30:26PM +0530, Jerin Jacob wrote:
> On Thu, Feb 1, 2024 at 3:05 PM Bruce Richardson
> wrote:
> >
> > On Fri, Jan 19, 2024 at 05:43:46PM +, Bruce Richardson wrote:
> > > Clarify the meaning of the NEW, FORWARD and RELEASE event types.
> > > For the fields in "rte_event" struct, enhance the comments on each to
> > > clarify the field's use, and whether it is preserved between enqueue and
> > > dequeue, and it's role, if any, in scheduling.
> > >
> > > Signed-off-by: Bruce Richardson
> > > ---
> > >
> > > As with the previous patch, please review this patch to ensure that the
> > > expected semantics of the various event types and event fields have not
> > > changed in an unexpected way.
> > > ---
> > > lib/eventdev/rte_eventdev.h | 105 ++--
> > > 1 file changed, 77 insertions(+), 28 deletions(-)
> > >
> >
> >
> > > #define RTE_EVENT_OP_RELEASE2
> > > /**< Release the flow context associated with the schedule type.
> > > *
> > > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ATOMIC*
> > > + * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_ATOMIC
> > > * then this function hints the scheduler that the user has completed
> > > critical
> > > * section processing in the current atomic context.
> > > * The scheduler is now allowed to schedule events from the same flow
> > > from
> > > @@ -1442,21 +1446,19 @@ struct rte_event_vector {
> > > * performance, but the user needs to design carefully the split into
> > > critical
> > > * vs non-critical sections.
> > > *
> > > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ORDERED*
> > > - * then this function hints the scheduler that the user has done all
> > > that need
> > > - * to maintain event order in the current ordered context.
> > > - * The scheduler is allowed to release the ordered context of this port
> > > and
> > > - * avoid reordering any following enqueues.
> > > - *
> > > - * Early ordered context release may increase parallelism and thus system
> > > - * performance.
> >
> > Before I do up a V3 of this patchset, I'd like to try and understand a bit
> > more what was meant by the original text for reordered here. The use of
> > "context" is very ambiguous, since it could refer to a number of different
> > things here.
> >
> > For me, RELEASE for ordered queues should mean much the same as for atomic
> > queues - it means that the event being released is to be "dropped" from the
> > point of view of the eventdev scheduler - i.e. any atomic locks held for
> > that event should be released, and any reordering slots for it should be
> > skipped. However, the text above seems to imply that when we release one
> > event it means that we should stop reordering all subsequent events for
> > that port - which seems wrong to me. Especially in the case where
> > reordering may be done per flow, does one release mean that we need to go
> > through all flows and mark as skipped all reordered slots awaiting returned
> > events from that port? If this is what is intended, how is it better than
> > just doing another dequeue call from the port, which releases everything
> > automatically anyway?
> >
> > Jerin, I believe you were the author of the original text, can you perhaps
> > clarify? Other PMD maintainers, can any of you chime in with current
> > supported behaviour when enqueuing a release of an ordered event?
>
> If N number of cores does rte_event_dequeue_burst() and got the same
> flow, and it is scheduled as
> RTE_SCHED_TYPE_ORDERED and then irrespective of the timing downstream
> rte_event_enqueue_burst()
> invocation any core. Upon rte_event_enqueue_burst() completion, the
> events will be enqueued the downstream
> queue in the ingress order.
>
> Assume, one of the core, calls RTE_EVENT_OP_RELEASE in between
> dequeue and enqueue, then that event no more
> eligible for the ingress order maintenance.
>
Thanks for the reply. Just to confirm my understanding - the RELEASE
applies to the event that is being skipped/dropped, which in a burst-mode
of operation i.e. when nb_dequeued > 1, other events may still be enqueued
from that burst and reordered appropriately. Correct?
/Bruce
Community CI Meeting Minutes - February 1, 2024
February 1, 2024 # Attendees 1. Patrick Robb 2. Paul Szczepanek 3. Thomas Monjalon 4. Juraj Linkes 5. Ali Alnubani 6. Aaron Conole # Minutes = General Announcements * Per mailing list/slack conversation, an important feature to add for the email based retest framework is to trigger a retest, but instead of retesting the original DPDK artifact created for the patchseries, re-apply on latest and retest. Ferruh suggests we include an optional argument “pull”, so if “pull=true” we re-apply on latest, if the argument is omitted or pull=false we do the normal behavior. * Some community members running automation are still pulling from the dpdk.org git server and need to move to github. People who don’t move will get blacklisted, and then they will move quickly. * Making periodic test results more visible: * Would be helpful to list the testing labels matrix for periodic “main” testing on the dpdk.org testing page (or a page under testing). * After main, we should add all branches, and should display datetime of test and branch name * Can also extend this to per patch testing. If we only include the latest patch tested, at least that shows all the labels tested. * Would be helpful to have a more detailed description. * We can do this in small steps, and just start with periodic testing. * Is there a problem with testing RFCs? UNH and GHA are not doing it, but should start. It does present a value to maintainers/developers and it probably does not present a testing capacity problem (most come early in a release cycle.) = CI Status - UNH-IOL Community Lab * Automation for TS-Factory testing is now online at UNH * Runs on ARM servers, for the XL710 NIC and MLNX CX5 * Runs 1x/month * Posts results to https://ts-factory.io/bublik/v2/runs * UNH team is still working on provisioning the new server donated by Intel * Requesting reviews/comments on Adam’s create artifact script (can be used in ci to leverage the pw_maintainers_cli.py tool for creating DPDK artifacts from new patchseries): https://inbox.dpdk.org/ci/20240118234120.29256-1-ahass...@iol.unh.edu/ * Rebuilding containers for all testing which has an ipsec-mb library dependency (fips, zuc, snow3g) due to the minimal version increasing to 1.4: https://inbox.dpdk.org/dev/20240130142412.2047550-1-venkatx.sivaramakrish...@intel.com/ - Intel Lab * No updates from John - Github Actions * Will be (within the next week) migrating the VM which runs the robot. The disruption should be about one half day. - Loongarch Lab * None = DTS Improvements & Test Development * We held a meeting yesterday for this. * We have someone at UNH starting now on this project (Nicholas Pratte), so we will see if he can start joining these meetings * Should update the bugzilla query for DTS to include the priority column so we can sort by that = Any other business * In the near future, we should change the week which ci meetings fall on, so that they are on the off week of the DTS meetings * Thomas will start saving the ci meeting minutes on the website * Next Meeting: February 15, 2024
Re: [PATCH] mem: explicitly initialise shared locks
On Fri, Oct 27, 2023 at 10:01 AM David Marchand wrote: > > Locks in the DPDK shared memory were not initialised so far. > This is not really a problem as the early_mem_config structure is stored > in the bss section (and so set to 0 by default). > Yet, for consistency, explicitly initialise those locks with relevant > initialiser macros. > > Suggested-by: Thomas Monjalon > Signed-off-by: David Marchand > Acked-by: Chengwen Feng Applied, thanks. -- David Marchand
[PATCH v7 1/2] drivers/net: fix buffer overflow for ptypes list
Address Sanitizer detects a buffer overflow caused by an incorrect
ptypes list. Missing "RTE_PTYPE_UNKNOWN" ptype causes buffer overflow.
Fix the ptypes list for drivers.
Fixes: 0849ac3b6122 ("net/tap: add packet type management")
Fixes: a7bdc3bd4244 ("net/dpaa: support packet type parsing")
Fixes: 4ccc8d770d3b ("net/mvneta: add PMD skeleton")
Fixes: f3f0d77db6b0 ("net/mrvl: support packet type parsing")
Fixes: 71e8bb65046e ("net/nfp: update supported list of packet types")
Fixes: 659b494d3d88 ("net/pfe: add packet types and basic statistics")
Fixes: 398a1be14168 ("net/thunderx: remove generic passX references")
Signed-off-by: Sivaramakrishnan Venkat
Reviewed-by: Ferruh Yigit
---
Cc: pascal.ma...@6wind.com
Cc: shreyansh.j...@nxp.com
Cc: z...@semihalf.com
Cc: t...@semihalf.com
Cc: qin...@corigine.com
Cc: g.si...@nxp.com
Cc: jerin.ja...@caviumnetworks.com
Cc: sta...@dpdk.org
v6: moved Cc email line after the "--" separator in the commit message.
v5: modified commit message.
v4: split into two patches, one for backporting and one for upstream rework
v3: reworked the function to return number of elements and remove the need
for RTE_PTYPE_UNKNOWN in list.
v2: extended fix for multiple drivers.
---
drivers/net/dpaa/dpaa_ethdev.c | 3 ++-
drivers/net/mvneta/mvneta_ethdev.c | 3 ++-
drivers/net/mvpp2/mrvl_ethdev.c | 3 ++-
drivers/net/nfp/nfp_net_common.c| 1 +
drivers/net/pfe/pfe_ethdev.c| 3 ++-
drivers/net/tap/rte_eth_tap.c | 1 +
drivers/net/thunderx/nicvf_ethdev.c | 2 ++
7 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dpaa/dpaa_ethdev.c b/drivers/net/dpaa/dpaa_ethdev.c
index ef4c06db6a..779bdc5860 100644
--- a/drivers/net/dpaa/dpaa_ethdev.c
+++ b/drivers/net/dpaa/dpaa_ethdev.c
@@ -363,7 +363,8 @@ dpaa_supported_ptypes_get(struct rte_eth_dev *dev)
RTE_PTYPE_L4_TCP,
RTE_PTYPE_L4_UDP,
RTE_PTYPE_L4_SCTP,
- RTE_PTYPE_TUNNEL_ESP
+ RTE_PTYPE_TUNNEL_ESP,
+ RTE_PTYPE_UNKNOWN
};
PMD_INIT_FUNC_TRACE();
diff --git a/drivers/net/mvneta/mvneta_ethdev.c
b/drivers/net/mvneta/mvneta_ethdev.c
index daa69e533a..212c300c14 100644
--- a/drivers/net/mvneta/mvneta_ethdev.c
+++ b/drivers/net/mvneta/mvneta_ethdev.c
@@ -198,7 +198,8 @@ mvneta_dev_supported_ptypes_get(struct rte_eth_dev *dev
__rte_unused)
RTE_PTYPE_L3_IPV4,
RTE_PTYPE_L3_IPV6,
RTE_PTYPE_L4_TCP,
- RTE_PTYPE_L4_UDP
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_UNKNOWN
};
return ptypes;
diff --git a/drivers/net/mvpp2/mrvl_ethdev.c b/drivers/net/mvpp2/mrvl_ethdev.c
index c12364941d..4cc64c7cad 100644
--- a/drivers/net/mvpp2/mrvl_ethdev.c
+++ b/drivers/net/mvpp2/mrvl_ethdev.c
@@ -1777,7 +1777,8 @@ mrvl_dev_supported_ptypes_get(struct rte_eth_dev *dev
__rte_unused)
RTE_PTYPE_L3_IPV6_EXT,
RTE_PTYPE_L2_ETHER_ARP,
RTE_PTYPE_L4_TCP,
- RTE_PTYPE_L4_UDP
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_UNKNOWN
};
return ptypes;
diff --git a/drivers/net/nfp/nfp_net_common.c b/drivers/net/nfp/nfp_net_common.c
index e969b840d6..46d0e07850 100644
--- a/drivers/net/nfp/nfp_net_common.c
+++ b/drivers/net/nfp/nfp_net_common.c
@@ -1299,6 +1299,7 @@ nfp_net_supported_ptypes_get(struct rte_eth_dev *dev)
RTE_PTYPE_INNER_L4_NONFRAG,
RTE_PTYPE_INNER_L4_ICMP,
RTE_PTYPE_INNER_L4_SCTP,
+ RTE_PTYPE_UNKNOWN
};
if (dev->rx_pkt_burst != nfp_net_recv_pkts)
diff --git a/drivers/net/pfe/pfe_ethdev.c b/drivers/net/pfe/pfe_ethdev.c
index 551f3cf193..0073dd7405 100644
--- a/drivers/net/pfe/pfe_ethdev.c
+++ b/drivers/net/pfe/pfe_ethdev.c
@@ -520,7 +520,8 @@ pfe_supported_ptypes_get(struct rte_eth_dev *dev)
RTE_PTYPE_L3_IPV6_EXT,
RTE_PTYPE_L4_TCP,
RTE_PTYPE_L4_UDP,
- RTE_PTYPE_L4_SCTP
+ RTE_PTYPE_L4_SCTP,
+ RTE_PTYPE_UNKNOWN
};
if (dev->rx_pkt_burst == pfe_recv_pkts ||
diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index b41fa971cb..3fa03cdbee 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -1803,6 +1803,7 @@ tap_dev_supported_ptypes_get(struct rte_eth_dev *dev
__rte_unused)
RTE_PTYPE_L4_UDP,
RTE_PTYPE_L4_TCP,
RTE_PTYPE_L4_SCTP,
+ RTE_PTYPE_UNKNOWN
};
return ptypes;
diff --git a/drivers/net/thunderx/nicvf_ethdev.c
b/drivers/net/thunderx/nicvf_ethdev.c
index a504d41dfe..5a0c3dc4a6 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -392,12 +392,14 @@ nicvf_dev_supported_ptypes_get(struct rte_eth_dev *dev)
RTE_PTYPE_L4_TCP,
RTE_PTYPE_L4_UDP,
[PATCH v7 1/2] drivers/net: fix buffer overflow for ptypes list
Address Sanitizer detects a buffer overflow caused by an incorrect
ptypes list. Missing "RTE_PTYPE_UNKNOWN" ptype causes buffer overflow.
Fix the ptypes list for drivers.
Fixes: 0849ac3b6122 ("net/tap: add packet type management")
Fixes: a7bdc3bd4244 ("net/dpaa: support packet type parsing")
Fixes: 4ccc8d770d3b ("net/mvneta: add PMD skeleton")
Fixes: f3f0d77db6b0 ("net/mrvl: support packet type parsing")
Fixes: 71e8bb65046e ("net/nfp: update supported list of packet types")
Fixes: 659b494d3d88 ("net/pfe: add packet types and basic statistics")
Fixes: 398a1be14168 ("net/thunderx: remove generic passX references")
Signed-off-by: Sivaramakrishnan Venkat
Reviewed-by: Ferruh Yigit
---
Cc: pascal.ma...@6wind.com
Cc: shreyansh.j...@nxp.com
Cc: z...@semihalf.com
Cc: t...@semihalf.com
Cc: qin...@corigine.com
Cc: g.si...@nxp.com
Cc: jerin.ja...@caviumnetworks.com
Cc: sta...@dpdk.org
v6: moved Cc email line after the "--" separator in the commit message.
v5: modified commit message.
v4: split into two patches, one for backporting and one for upstream rework
v3: reworked the function to return number of elements and remove the need
for RTE_PTYPE_UNKNOWN in list.
v2: extended fix for multiple drivers.
---
drivers/net/dpaa/dpaa_ethdev.c | 3 ++-
drivers/net/mvneta/mvneta_ethdev.c | 3 ++-
drivers/net/mvpp2/mrvl_ethdev.c | 3 ++-
drivers/net/nfp/nfp_net_common.c| 1 +
drivers/net/pfe/pfe_ethdev.c| 3 ++-
drivers/net/tap/rte_eth_tap.c | 1 +
drivers/net/thunderx/nicvf_ethdev.c | 2 ++
7 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dpaa/dpaa_ethdev.c b/drivers/net/dpaa/dpaa_ethdev.c
index ef4c06db6a..779bdc5860 100644
--- a/drivers/net/dpaa/dpaa_ethdev.c
+++ b/drivers/net/dpaa/dpaa_ethdev.c
@@ -363,7 +363,8 @@ dpaa_supported_ptypes_get(struct rte_eth_dev *dev)
RTE_PTYPE_L4_TCP,
RTE_PTYPE_L4_UDP,
RTE_PTYPE_L4_SCTP,
- RTE_PTYPE_TUNNEL_ESP
+ RTE_PTYPE_TUNNEL_ESP,
+ RTE_PTYPE_UNKNOWN
};
PMD_INIT_FUNC_TRACE();
diff --git a/drivers/net/mvneta/mvneta_ethdev.c
b/drivers/net/mvneta/mvneta_ethdev.c
index daa69e533a..212c300c14 100644
--- a/drivers/net/mvneta/mvneta_ethdev.c
+++ b/drivers/net/mvneta/mvneta_ethdev.c
@@ -198,7 +198,8 @@ mvneta_dev_supported_ptypes_get(struct rte_eth_dev *dev
__rte_unused)
RTE_PTYPE_L3_IPV4,
RTE_PTYPE_L3_IPV6,
RTE_PTYPE_L4_TCP,
- RTE_PTYPE_L4_UDP
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_UNKNOWN
};
return ptypes;
diff --git a/drivers/net/mvpp2/mrvl_ethdev.c b/drivers/net/mvpp2/mrvl_ethdev.c
index c12364941d..4cc64c7cad 100644
--- a/drivers/net/mvpp2/mrvl_ethdev.c
+++ b/drivers/net/mvpp2/mrvl_ethdev.c
@@ -1777,7 +1777,8 @@ mrvl_dev_supported_ptypes_get(struct rte_eth_dev *dev
__rte_unused)
RTE_PTYPE_L3_IPV6_EXT,
RTE_PTYPE_L2_ETHER_ARP,
RTE_PTYPE_L4_TCP,
- RTE_PTYPE_L4_UDP
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_UNKNOWN
};
return ptypes;
diff --git a/drivers/net/nfp/nfp_net_common.c b/drivers/net/nfp/nfp_net_common.c
index e969b840d6..46d0e07850 100644
--- a/drivers/net/nfp/nfp_net_common.c
+++ b/drivers/net/nfp/nfp_net_common.c
@@ -1299,6 +1299,7 @@ nfp_net_supported_ptypes_get(struct rte_eth_dev *dev)
RTE_PTYPE_INNER_L4_NONFRAG,
RTE_PTYPE_INNER_L4_ICMP,
RTE_PTYPE_INNER_L4_SCTP,
+ RTE_PTYPE_UNKNOWN
};
if (dev->rx_pkt_burst != nfp_net_recv_pkts)
diff --git a/drivers/net/pfe/pfe_ethdev.c b/drivers/net/pfe/pfe_ethdev.c
index 551f3cf193..0073dd7405 100644
--- a/drivers/net/pfe/pfe_ethdev.c
+++ b/drivers/net/pfe/pfe_ethdev.c
@@ -520,7 +520,8 @@ pfe_supported_ptypes_get(struct rte_eth_dev *dev)
RTE_PTYPE_L3_IPV6_EXT,
RTE_PTYPE_L4_TCP,
RTE_PTYPE_L4_UDP,
- RTE_PTYPE_L4_SCTP
+ RTE_PTYPE_L4_SCTP,
+ RTE_PTYPE_UNKNOWN
};
if (dev->rx_pkt_burst == pfe_recv_pkts ||
diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index b41fa971cb..3fa03cdbee 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -1803,6 +1803,7 @@ tap_dev_supported_ptypes_get(struct rte_eth_dev *dev
__rte_unused)
RTE_PTYPE_L4_UDP,
RTE_PTYPE_L4_TCP,
RTE_PTYPE_L4_SCTP,
+ RTE_PTYPE_UNKNOWN
};
return ptypes;
diff --git a/drivers/net/thunderx/nicvf_ethdev.c
b/drivers/net/thunderx/nicvf_ethdev.c
index a504d41dfe..5a0c3dc4a6 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -392,12 +392,14 @@ nicvf_dev_supported_ptypes_get(struct rte_eth_dev *dev)
RTE_PTYPE_L4_TCP,
RTE_PTYPE_L4_UDP,
[PATCH v7 2/2] drivers/net: return number of types in get supported types
Missing "RTE_PTYPE_UNKNOWN" ptype causes buffer overflow. Enhance code such that the dev_supported_ptypes_get() function pointer now returns the number of elements to eliminate the need for "RTE_PTYPE_UNKNOWN" as the last item. Signed-off-by: Sivaramakrishnan Venkat --- v7: - tidied formatting of code. - updated the code to keep the terminating char ',' for missed ptypes array. - nicvf_dev_supported_ptypes_get() updated to get the correct the no of elements. v6: - missed drivers reworked for the removal of RTE_PTYPE_UNKNOWN in list. - added code back in that incorrectly removed in v5 for set_ptypes function last element. v5: - modified commit message. - tidied formatting of code. - added doxygen comment. v4: - split into two patches, one for backporting and another one for upstream rework. v3: - reworked the function to return number of elements and remove the need for RTE_PTYPE_UNKNOWN in list. v2: - extended fix for multiple drivers. --- drivers/net/atlantic/atl_ethdev.c | 10 ++ drivers/net/axgbe/axgbe_ethdev.c | 10 ++ drivers/net/bnxt/bnxt_ethdev.c | 5 +++-- drivers/net/cnxk/cnxk_ethdev.h | 3 ++- drivers/net/cnxk/cnxk_lookup.c | 7 --- drivers/net/cpfl/cpfl_ethdev.c | 5 +++-- drivers/net/cxgbe/cxgbe_ethdev.c | 8 +--- drivers/net/cxgbe/cxgbe_pfvf.h | 3 ++- drivers/net/dpaa/dpaa_ethdev.c | 7 --- drivers/net/dpaa2/dpaa2_ethdev.c | 7 --- drivers/net/e1000/igb_ethdev.c | 10 ++ drivers/net/enetc/enetc_ethdev.c | 5 +++-- drivers/net/enic/enic_ethdev.c | 12 +++- drivers/net/failsafe/failsafe_ops.c| 4 ++-- drivers/net/fm10k/fm10k_ethdev.c | 9 + drivers/net/hns3/hns3_rxtx.c | 11 ++- drivers/net/hns3/hns3_rxtx.h | 3 ++- drivers/net/i40e/i40e_rxtx.c | 7 --- drivers/net/i40e/i40e_rxtx.h | 3 ++- drivers/net/iavf/iavf_ethdev.c | 8 +--- drivers/net/ice/ice_dcf_ethdev.c | 5 +++-- drivers/net/ice/ice_ethdev.c | 8 +--- drivers/net/ice/ice_rxtx.c | 11 ++- drivers/net/ice/ice_rxtx.h | 3 ++- drivers/net/idpf/idpf_ethdev.c | 5 +++-- drivers/net/igc/igc_ethdev.c | 8 +--- drivers/net/ionic/ionic_rxtx.c | 5 +++-- drivers/net/ionic/ionic_rxtx.h | 3 ++- drivers/net/ixgbe/ixgbe_ethdev.c | 14 - drivers/net/mana/mana.c| 5 +++-- drivers/net/mlx4/mlx4.h| 3 ++- drivers/net/mlx4/mlx4_ethdev.c | 11 ++- drivers/net/mlx5/mlx5.h| 3 ++- drivers/net/mlx5/mlx5_ethdev.c | 7 --- drivers/net/mvneta/mvneta_ethdev.c | 5 +++-- drivers/net/mvpp2/mrvl_ethdev.c| 5 +++-- drivers/net/netvsc/hn_var.h| 3 ++- drivers/net/netvsc/hn_vf.c | 6 -- drivers/net/nfp/nfp_net_common.c | 4 ++-- drivers/net/nfp/nfp_net_common.h | 3 ++- drivers/net/ngbe/ngbe_ethdev.c | 4 ++-- drivers/net/ngbe/ngbe_ethdev.h | 3 ++- drivers/net/ngbe/ngbe_ptypes.c | 4 ++-- drivers/net/ngbe/ngbe_ptypes.h | 2 +- drivers/net/octeontx/octeontx_ethdev.c | 9 + drivers/net/pfe/pfe_ethdev.c | 7 --- drivers/net/qede/qede_ethdev.c | 8 +--- drivers/net/sfc/sfc_dp_rx.h| 2 +- drivers/net/sfc/sfc_ef10.h | 3 ++- drivers/net/sfc/sfc_ef100_rx.c | 5 +++-- drivers/net/sfc/sfc_ef10_rx.c | 6 +++--- drivers/net/sfc/sfc_ethdev.c | 5 +++-- drivers/net/sfc/sfc_rx.c | 5 +++-- drivers/net/tap/rte_eth_tap.c | 5 +++-- drivers/net/thunderx/nicvf_ethdev.c| 7 ++- drivers/net/txgbe/txgbe_ethdev.c | 4 ++-- drivers/net/txgbe/txgbe_ethdev.h | 3 ++- drivers/net/txgbe/txgbe_ptypes.c | 4 ++-- drivers/net/txgbe/txgbe_ptypes.h | 2 +- drivers/net/vmxnet3/vmxnet3_ethdev.c | 11 +++ lib/ethdev/ethdev_driver.h | 21 +--- lib/ethdev/rte_ethdev.c| 27 +- 62 files changed, 243 insertions(+), 158 deletions(-) diff --git a/drivers/net/atlantic/atl_ethdev.c b/drivers/net/atlantic/atl_ethdev.c index 3a028f4290..9cde935834 100644 --- a/drivers/net/atlantic/atl_ethdev.c +++ b/drivers/net/atlantic/atl_ethdev.c @@ -43,7 +43,8 @@ static int atl_dev_stats_reset(struct rte_eth_dev *dev); static int atl_fw_version_get(struct rte_eth_dev *dev, char *fw_version, size_t fw_size); -static const uint32_t *atl_dev_supported_ptypes_get(struct rte_eth_dev *dev); +static const uint32_t *atl_dev_supported_ptypes_get(struct rte_eth_dev *dev, + size_t *no_of_elements); static int atl_dev_mtu_set(struct rt
Re: [PATCH v2 0/2] support NAT64 action
On Wed, 31 Jan 2024 11:38:02 +0200, Bing Zhao wrote: > This patchset introduce the NAT64 action support for rte_flow. > Applied, thanks! [1/2] ethdev: introduce NAT64 action commit: 8d06f5a2da9991ebd514869a72f5136e0ee1eaf1 [2/2] app/testpmd: add support for NAT64 in the command line commit: 1d14e0581427004de88ac95e25529761f4492621 Best regards, -- Ferruh Yigit
Re: [PATCH v2 0/2] support NAT64 action
On 2/1/2024 4:00 PM, Ferruh Yigit wrote: > > On Wed, 31 Jan 2024 11:38:02 +0200, Bing Zhao wrote: >> This patchset introduce the NAT64 action support for rte_flow. >> > > Applied, thanks! > > [1/2] ethdev: introduce NAT64 action > commit: 8d06f5a2da9991ebd514869a72f5136e0ee1eaf1 > [2/2] app/testpmd: add support for NAT64 in the command line > commit: 1d14e0581427004de88ac95e25529761f4492621 > > Best regards, > Hi sub-tree maintainers, I sent above applied message from console using "b4 ty" tool [1], in case it helps you, FYI. [1] https://www.mankier.com/5/b4#Subcommand_Options-b4_ty
Re: [Patch v3] net/mana: use rte_pktmbuf_alloc_bulk for allocating RX WQEs
On Wed, Jan 31, 2024 at 07:45:50PM -0800, lon...@linuxonhyperv.com wrote:
> From: Long Li
>
> Instead of allocating mbufs one by one during RX, use
> rte_pktmbuf_alloc_bulk() to allocate them in a batch.
>
> There are no measurable performance improvements in benchmarks. However,
> this patch should improve CPU cycles and reduce potential locking
> conflicts in real-world applications.
>
> Signed-off-by: Long Li
> ---
> Change in v2:
> use rte_calloc_socket() in place of rte_calloc()
>
> v3:
> add more comment explaining the benefit of doing alloc_bulk.
> free mbufs that are failed to post
>
> drivers/net/mana/rx.c | 74 +--
> 1 file changed, 50 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/net/mana/rx.c b/drivers/net/mana/rx.c
> index acad5e26cd..6112db2219 100644
> --- a/drivers/net/mana/rx.c
> +++ b/drivers/net/mana/rx.c
> @@ -2,6 +2,7 @@
> * Copyright 2022 Microsoft Corporation
> */
> #include
> +#include
>
> #include
> #include
> @@ -59,9 +60,8 @@ mana_rq_ring_doorbell(struct mana_rxq *rxq)
> }
>
> static int
> -mana_alloc_and_post_rx_wqe(struct mana_rxq *rxq)
> +mana_post_rx_wqe(struct mana_rxq *rxq, struct rte_mbuf *mbuf)
> {
> - struct rte_mbuf *mbuf = NULL;
> struct gdma_sgl_element sgl[1];
> struct gdma_work_request request;
> uint32_t wqe_size_in_bu;
> @@ -69,12 +69,6 @@ mana_alloc_and_post_rx_wqe(struct mana_rxq *rxq)
> int ret;
> struct mana_mr_cache *mr;
>
> - mbuf = rte_pktmbuf_alloc(rxq->mp);
> - if (!mbuf) {
> - rxq->stats.nombuf++;
> - return -ENOMEM;
> - }
> -
> mr = mana_alloc_pmd_mr(&rxq->mr_btree, priv, mbuf);
> if (!mr) {
> DP_LOG(ERR, "failed to register RX MR");
> @@ -121,19 +115,32 @@ mana_alloc_and_post_rx_wqe(struct mana_rxq *rxq)
> * Post work requests for a Rx queue.
> */
> static int
> -mana_alloc_and_post_rx_wqes(struct mana_rxq *rxq)
> +mana_alloc_and_post_rx_wqes(struct mana_rxq *rxq, uint32_t count)
> {
> int ret;
> uint32_t i;
> + struct rte_mbuf **mbufs;
> +
> + mbufs = rte_calloc_socket("mana_rx_mbufs", count, sizeof(struct
> rte_mbuf *),
> + 0, rxq->mp->socket_id);
> + if (!mbufs)
> + return -ENOMEM;
> +
> + ret = rte_pktmbuf_alloc_bulk(rxq->mp, mbufs, count);
> + if (ret) {
> + DP_LOG(ERR, "failed to allocate mbufs for RX");
> + rxq->stats.nombuf += count;
> + goto fail;
> + }
>
> #ifdef RTE_ARCH_32
> rxq->wqe_cnt_to_short_db = 0;
> #endif
> - for (i = 0; i < rxq->num_desc; i++) {
> - ret = mana_alloc_and_post_rx_wqe(rxq);
> + for (i = 0; i < count; i++) {
> + ret = mana_post_rx_wqe(rxq, mbufs[i]);
> if (ret) {
> DP_LOG(ERR, "failed to post RX ret = %d", ret);
> - return ret;
> + break;
> }
>
> #ifdef RTE_ARCH_32
> @@ -144,8 +151,16 @@ mana_alloc_and_post_rx_wqes(struct mana_rxq *rxq)
> #endif
> }
>
> + /* Free the remaining mbufs that are not posted */
> + while (i < count) {
> + rte_pktmbuf_free(mbufs[i]);
> + i++;
> + }
there is also rte_pktmbuf_free_bulk() that could be used. probably won't
make any material difference to perf though so just an fyi.
Re: [PATCH v2 11/11] eventdev: RFC clarify docs on event object fields
On Thu, Feb 1, 2024 at 8:54 PM Bruce Richardson
wrote:
>
> On Thu, Feb 01, 2024 at 08:30:26PM +0530, Jerin Jacob wrote:
> > On Thu, Feb 1, 2024 at 3:05 PM Bruce Richardson
> > wrote:
> > >
> > > On Fri, Jan 19, 2024 at 05:43:46PM +, Bruce Richardson wrote:
> > > > Clarify the meaning of the NEW, FORWARD and RELEASE event types.
> > > > For the fields in "rte_event" struct, enhance the comments on each to
> > > > clarify the field's use, and whether it is preserved between enqueue and
> > > > dequeue, and it's role, if any, in scheduling.
> > > >
> > > > Signed-off-by: Bruce Richardson
> > > > ---
> > > >
> > > > As with the previous patch, please review this patch to ensure that the
> > > > expected semantics of the various event types and event fields have not
> > > > changed in an unexpected way.
> > > > ---
> > > > lib/eventdev/rte_eventdev.h | 105 ++--
> > > > 1 file changed, 77 insertions(+), 28 deletions(-)
> > > >
> > >
> > >
> > > > #define RTE_EVENT_OP_RELEASE2
> > > > /**< Release the flow context associated with the schedule type.
> > > > *
> > > > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ATOMIC*
> > > > + * If current flow's scheduler type method is @ref
> > > > RTE_SCHED_TYPE_ATOMIC
> > > > * then this function hints the scheduler that the user has completed
> > > > critical
> > > > * section processing in the current atomic context.
> > > > * The scheduler is now allowed to schedule events from the same flow
> > > > from
> > > > @@ -1442,21 +1446,19 @@ struct rte_event_vector {
> > > > * performance, but the user needs to design carefully the split into
> > > > critical
> > > > * vs non-critical sections.
> > > > *
> > > > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ORDERED*
> > > > - * then this function hints the scheduler that the user has done all
> > > > that need
> > > > - * to maintain event order in the current ordered context.
> > > > - * The scheduler is allowed to release the ordered context of this
> > > > port and
> > > > - * avoid reordering any following enqueues.
> > > > - *
> > > > - * Early ordered context release may increase parallelism and thus
> > > > system
> > > > - * performance.
> > >
> > > Before I do up a V3 of this patchset, I'd like to try and understand a bit
> > > more what was meant by the original text for reordered here. The use of
> > > "context" is very ambiguous, since it could refer to a number of different
> > > things here.
> > >
> > > For me, RELEASE for ordered queues should mean much the same as for atomic
> > > queues - it means that the event being released is to be "dropped" from
> > > the
> > > point of view of the eventdev scheduler - i.e. any atomic locks held for
> > > that event should be released, and any reordering slots for it should be
> > > skipped. However, the text above seems to imply that when we release one
> > > event it means that we should stop reordering all subsequent events for
> > > that port - which seems wrong to me. Especially in the case where
> > > reordering may be done per flow, does one release mean that we need to go
> > > through all flows and mark as skipped all reordered slots awaiting
> > > returned
> > > events from that port? If this is what is intended, how is it better than
> > > just doing another dequeue call from the port, which releases everything
> > > automatically anyway?
> > >
> > > Jerin, I believe you were the author of the original text, can you perhaps
> > > clarify? Other PMD maintainers, can any of you chime in with current
> > > supported behaviour when enqueuing a release of an ordered event?
> >
> > If N number of cores does rte_event_dequeue_burst() and got the same
> > flow, and it is scheduled as
> > RTE_SCHED_TYPE_ORDERED and then irrespective of the timing downstream
> > rte_event_enqueue_burst()
> > invocation any core. Upon rte_event_enqueue_burst() completion, the
> > events will be enqueued the downstream
> > queue in the ingress order.
> >
> > Assume, one of the core, calls RTE_EVENT_OP_RELEASE in between
> > dequeue and enqueue, then that event no more
> > eligible for the ingress order maintenance.
> >
> Thanks for the reply. Just to confirm my understanding - the RELEASE
> applies to the event that is being skipped/dropped, which in a burst-mode
> of operation i.e. when nb_dequeued > 1, other events may still be enqueued
> from that burst and reordered appropriately. Correct?
Yes. That's my understanding too.
>
> /Bruce
Re: [Patch v2] net/mana: use rte_pktmbuf_alloc_bulk for allocating RX WQEs
On Thu, Feb 01, 2024 at 03:55:55AM +, Long Li wrote: > > >> 'mbufs' is temporarily storage for allocated mbuf pointers, why not > > >> allocate if from stack instead, can be faster and easier to manage: > > >> "struct rte_mbuf *mbufs[count]" > > > > > > That would introduce a variable length array. > > > VLA's should be removed, they are not supported on Windows and many > > > security tools flag them. The problem is that it makes the code > > > brittle if count gets huge. > > > > > > But certainly regular calloc() or alloca() would work here. > > > > > > > Most of the existing bulk alloc already uses VLA but I can see the problem > > it is not > > being supported by Windows. > > > > As this mbuf pointer array is short lived within the function, and being in > > the fast > > path, I think continuous alloc and free can be prevented, > > > > one option can be to define a fixed size, big enough, array which requires > > additional loop for the cases 'count' size is bigger than array size, > > > > or an array can be allocated by driver init in device specific data ,as we > > know it > > will be required continuously in the datapath, and it can be freed during > > device > > close()/uninit(). > > > > I think an fixed size array from stack is easier and can be preferred. > > I sent a v3 of the patch, still using alloc(). > > I found two problems with using a fixed array: > 1. the array size needs to be determined in advance. I don't know what a good > number should be. If too big, some of them may be wasted. (and maybe make a > bigger mess of CPU cache) If too small, it ends up doing multiple > allocations, which is the problem this patch trying to solve. > 2. if makes the code slightly more complex ,but I think 1 is the main problem. > > I think another approach is to use VLA by default, but for Windows use > alloc(). a few thoughts on VLAs you may consider. not to be regarded as a strong objection. indications are that standard C will gradually phase out VLAs because they're generally accepted as having been a bad idea. that said compilers that implement them will probably keep them forever. VLAs generate a lot of code relative to just using a more permanent allocation. may not show up in your performance tests but you also may not want it on your hotpath either. mana doesn't currently support windows, are there plans to support windows? if never then i suppose VLAs can be used since all the toolchains you care about have them. though it does raise the bar, cause more work, later refactor, carry regression risk should you change your mind and choose to port to windows. accepting the use of VLAs anywhere in dpdk prohibits general checkpatches and/or compiling with compiler options that detect and flag their inclusion as a part of the CI without having to add exclusion logic for drivers that are allowed to use them. > > Long
Re: [PATCH v3 1/2] config/arm: allow WFE to be enabled config time
On Mon, Jan 22, 2024 at 12:13 PM Ruifeng Wang wrote: > > > On 2024/1/21 11:21 PM, pbhagavat...@marvell.com wrote: > > From: Pavan Nikhilesh > > > > Allow RTE_ARM_USE_WFE to be enabled at meson configuration > > time by passing it via c_args instead of modifying > > `config/arm/meson.build`. > > > > Example usage: > > meson build -Dc_args='-DRTE_ARM_USE_WFE' \ > > --cross-file config/arm/arm64_cn10k_linux_gcc > > > > Signed-off-by: Pavan Nikhilesh Could you split and resend this series a two separate patch as this patch needs to go through main tree.
Re: [PATCH v3 2/2] net/octeon_ep: add Rx NEON routine
On Sun, Jan 21, 2024 at 10:13 PM wrote: > > From: Pavan Nikhilesh > > Add Rx ARM NEON SIMD routine. > > Signed-off-by: Pavan Nikhilesh Please fix https://mails.dpdk.org/archives/test-report/2024-January/559746.html https://patches.dpdk.org/project/dpdk/patch/20240121164334.9269-2-pbhagavat...@marvell.com/
Re: [PATCH] telemetry: avoid truncation of strlcpy return before check
On Thu, Feb 01, 2024 at 12:45:43PM +0100, David Marchand wrote:
> On Tue, Aug 8, 2023 at 8:35 PM Bruce Richardson
> wrote:
> >
> > On Tue, Aug 08, 2023 at 10:59:37AM -0700, Tyler Retzlaff wrote:
> > > On Tue, Aug 08, 2023 at 10:24:41AM +0800, lihuisong (C) wrote:
> > > >
> > > > 在 2023/8/3 5:21, Tyler Retzlaff 写道:
> > > > >strlcpy returns type size_t when directly assigning to
> > > > >struct rte_tel_data data_len field it may be truncated leading to
> > > > >compromised length check that follows
> > > > >
> > > > >Since the limit in the check is < UINT_MAX the value returned is
> > > > >safe to be cast to unsigned int (which may be narrower than size_t)
> > > > >but only after being checked against RTE_TEL_MAX_SINGLE_STRING_LEN
> > > > >
> > > > >Signed-off-by: Tyler Retzlaff
> > > > >---
> > > > > lib/telemetry/telemetry_data.c | 5 +++--
> > > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > > >
> > > > >diff --git a/lib/telemetry/telemetry_data.c
> > > > >b/lib/telemetry/telemetry_data.c
> > > > >index 3b1a240..52307cb 100644
> > > > >--- a/lib/telemetry/telemetry_data.c
> > > > >+++ b/lib/telemetry/telemetry_data.c
> > > > >@@ -41,12 +41,13 @@
> > > > > int
> > > > > rte_tel_data_string(struct rte_tel_data *d, const char *str)
> > > > > {
> > > > >+ const size_t len = strlcpy(d->data.str, str, sizeof(d->data.str));
> > > > sizeof(d->data.str) is equal to RTE_TEL_MAX_SINGLE_STRING_LEN(8192).
> > > > So It seems that this truncation probably will not happen.
> > >
> > > agreed, regardless the data type choices permit a size that exceeds the
> > > range of the narrower type and the assignment results in a warning being
> > > generated on some targets. that's why the truncating cast is safe to
> > > add.
> > >
> > > none of this would be necessary if data_len had been appropriately typed
> > > as size_t. Bruce should we be changing the type instead since we are in
> > > 23.11 merge window...?
> > >
> > I'm fine either way, to be honest.
>
> Can we conclude?
> struct rte_tel_data seems internal (at least opaque from an
> application pov), so I suppose the option of changing data_len to
> size_t is still on the table.
>
> And we are missing a Fixes: tag too.
there is actually a general pattern of this problem across dpdk tree and
this fixes one instance.
i've marked the patch as rejected for now and hope to come back with a
more comprehensive series after msvc work is merged.
ty
>
> Thanks.
>
> --
> David Marchand
Re: [PATCH v2 11/11] eventdev: RFC clarify docs on event object fields
On Wed, Jan 24, 2024 at 12:34:50PM +0100, Mattias Rönnblom wrote:
> On 2024-01-19 18:43, Bruce Richardson wrote:
> > Clarify the meaning of the NEW, FORWARD and RELEASE event types.
> > For the fields in "rte_event" struct, enhance the comments on each to
> > clarify the field's use, and whether it is preserved between enqueue and
> > dequeue, and it's role, if any, in scheduling.
> >
> > Signed-off-by: Bruce Richardson
> > ---
> >
> > As with the previous patch, please review this patch to ensure that the
> > expected semantics of the various event types and event fields have not
> > changed in an unexpected way.
> > ---
> > lib/eventdev/rte_eventdev.h | 105 ++--
> > 1 file changed, 77 insertions(+), 28 deletions(-)
> >
> > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> > index cb13602ffb..4eff1c4958 100644
> > --- a/lib/eventdev/rte_eventdev.h
> > +++ b/lib/eventdev/rte_eventdev.h
> > @@ -1416,21 +1416,25 @@ struct rte_event_vector {
> >
> > /* Event enqueue operations */
> > #define RTE_EVENT_OP_NEW0
> > -/**< The event producers use this operation to inject a new event to the
> > +/**< The @ref rte_event.op field should be set to this type to inject a
> > new event to the
> >* event device.
> >*/
>
> "type" -> "value"
>
> "to" -> "into"?
>
> You could also say "to mark the event as new".
>
> What is new? Maybe "new (as opposed to a forwarded) event." or "new (i.e.,
> not previously dequeued).".
>
Using this latter suggested wording in V3.
> "The application sets the @ref rte_event.op field of an enqueued event to
> this value to mark the event as new (i.e., not previously dequeued)."
>
> > #define RTE_EVENT_OP_FORWARD1
> > -/**< The CPU use this operation to forward the event to different event
> > queue or
> > - * change to new application specific flow or schedule type to enable
> > - * pipelining.
> > +/**< SW should set the @ref rte_event.op filed to this type to return a
> > + * previously dequeued event to the event device for further processing.
>
> "filed" -> "field"
>
> "SW" -> "The application"
>
> "to be scheduled for further processing (or transmission)"
>
> The wording should otherwise be the same as NEW, whatever you choose there.
>
Ack.
> >*
> > - * This operation must only be enqueued to the same port that the
> > + * This event *must* be enqueued to the same port that the
> >* event to be forwarded was dequeued from.
>
> OK, so you "should" mark a new event RTE_EVENT_OP_FORWARD but you "*must*"
> enqueue it to the same port.
>
> I think you "must" do both.
>
Ack
> > + *
> > + * The event's fields, including (but not limited to) flow_id, scheduling
> > type,
> > + * destination queue, and event payload e.g. mbuf pointer, may all be
> > updated as
> > + * desired by software, but the @ref rte_event.impl_opaque field must
>
> "software" -> "application"
>
Ack
> > + * be kept to the same value as was present when the event was dequeued.
> >*/
> > #define RTE_EVENT_OP_RELEASE2
> > /**< Release the flow context associated with the schedule type.
> >*
> > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ATOMIC*
> > + * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_ATOMIC
> >* then this function hints the scheduler that the user has completed
> > critical
> >* section processing in the current atomic context.
> >* The scheduler is now allowed to schedule events from the same flow from
> > @@ -1442,21 +1446,19 @@ struct rte_event_vector {
> >* performance, but the user needs to design carefully the split into
> > critical
> >* vs non-critical sections.
> >*
> > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_ORDERED*
> > - * then this function hints the scheduler that the user has done all that
> > need
> > - * to maintain event order in the current ordered context.
> > - * The scheduler is allowed to release the ordered context of this port and
> > - * avoid reordering any following enqueues.
> > - *
> > - * Early ordered context release may increase parallelism and thus system
> > - * performance.
> > + * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_ORDERED
>
> Isn't a missing "or @ref RTE_SCHED_TYPE_ATOMIC" just an oversight (in the
> original API wording)?
>
No, I don't think so, because ATOMIC is described above.
> > + * then this function informs the scheduler that the current event has
> > + * completed processing and will not be returned to the scheduler, i.e.
> > + * it has been dropped, and so the reordering context for that event
> > + * should be considered filled.
> >*
> > - * If current flow's scheduler type method is *RTE_SCHED_TYPE_PARALLEL*
> > + * If current flow's scheduler type method is @ref RTE_SCHED_TYPE_PARALLEL
> >* or no scheduling context is held then this function may be an NOOP,
> >* depending on t
Re: [PATCH v2 11/11] eventdev: RFC clarify docs on event object fields
On Wed, Jan 24, 2024 at 12:34:50PM +0100, Mattias Rönnblom wrote:
> On 2024-01-19 18:43, Bruce Richardson wrote:
> > Clarify the meaning of the NEW, FORWARD and RELEASE event types.
> > For the fields in "rte_event" struct, enhance the comments on each to
> > clarify the field's use, and whether it is preserved between enqueue and
> > dequeue, and it's role, if any, in scheduling.
> >
> > Signed-off-by: Bruce Richardson
> > ---
> >
> > As with the previous patch, please review this patch to ensure that the
> > expected semantics of the various event types and event fields have not
> > changed in an unexpected way.
> > ---
> > lib/eventdev/rte_eventdev.h | 105 ++--
> > 1 file changed, 77 insertions(+), 28 deletions(-)
> >
> > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> > index cb13602ffb..4eff1c4958 100644
> > --- a/lib/eventdev/rte_eventdev.h
> > +++ b/lib/eventdev/rte_eventdev.h
> > /**
> > @@ -1473,53 +1475,100 @@ struct rte_event {
> > /**< Targeted flow identifier for the enqueue and
> > * dequeue operation.
> > * The value must be in the range of
> > -* [0, nb_event_queue_flows - 1] which
> > +* [0, @ref rte_event_dev_config.nb_event_queue_flows -
> > 1] which
>
> The same comment as I had before about ranges for unsigned types.
>
Actually, is this correct, does a range actually apply here?
I thought that the number of queue flows supported was a guide as to how
internal HW resources were to be allocated, and that the flow_id was always
a 20-bit value, where it was up to the scheduler to work out how to map
that to internal atomic locks (when combined with queue ids etc.). It
should not be up to the app to have to do the range limiting itself!
/Bruce
Re: [PATCH] test/event: skip test if no driver is present
On Wed, Jan 24, 2024 at 6:03 PM David Marchand
wrote:
>
> Align eventdev with what other device abstraction libraries do: if no
> driver is present, skip the tests.
>
> Fixes: f8f9d233ea0e ("test/eventdev: add unit tests")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand
Applied to dpdk-next-eventdev/for-main. Thanks
> ---
> app/test/test_eventdev.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/app/test/test_eventdev.c b/app/test/test_eventdev.c
> index 71de947ce4..e4e234dc98 100644
> --- a/app/test/test_eventdev.c
> +++ b/app/test/test_eventdev.c
> @@ -33,9 +33,15 @@ testsuite_setup(void)
> uint8_t count;
> count = rte_event_dev_count();
> if (!count) {
> + int ret;
> +
> printf("Failed to find a valid event device,"
> - " testing with event_skeleton device\n");
> - return rte_vdev_init("event_skeleton", NULL);
> + " trying with event_skeleton device\n");
> + ret = rte_vdev_init("event_skeleton", NULL);
> + if (ret != 0) {
> + printf("No event device, skipping\n");
> + return TEST_SKIPPED;
> + }
> }
> return TEST_SUCCESS;
> }
> --
> 2.43.0
>
Re: [PATCH v5 0/2] multiple representors in one device
On 2/1/2024 10:02 AM, Harman Kalra wrote: > Following series adds support to enable creation of multiple representors > under one base device. There may be scenarios where port representors for > multiple PFs or VFs under PF are required and all these representor ports > created under a single pci device. Marvell CNXK port representor solution > is designed around this scenario where all representors are backed by a > single switch device. > > Earlier this change was implemented as part of the Marvell CNXK port > representor series but after suggestions from Thomas we would like > to propose these changes in common code. > https://patches.dpdk.org/project/dpdk/patch/20231219174003.72901-25-hka...@marvell.com/#166785 > > V5: > - Added test cases to demonstrate valid and invalid cases > - changed the tokenizing logic to address all valid cases > > V4: > - Used MT safe strtok_r in place of strtok > - Reworded some comments > > V3: > - Fix duplicate representor devarg key handling logic > > V2: > - Updated the multiple representor devarg pattern to list > i.e. representor=[pf[0-1],pf2vf[1,2-3],[4-5]] > - Introduced size of array as third argument to rte_eth_devargs_parse() > to avoid array corruption > - Squashed separate document patch > > > Harman Kalra (2): > ethdev: parsing multiple representor devargs string > test/devargs: add eth devargs parse cases > Reviewed-by: Ferruh Yigit Squashed patches while merging, Series applied to dpdk-next-net/main, thanks.
Re: [PATCH v5 0/3] ethdev: add RTE_FLOW_ITEM_TYPE_COMPARE
On 2/1/2024 12:29 PM, Suanming Mou wrote: > The new item type is added for the case user wants to match traffic > based on packet field compare result with other fields or immediate > value. > > e.g. take advantage the compare item user will be able to accumulate > a IPv4/TCP packet's TCP data_offset and IPv4 IHL field to a tag > register, then compare the tag register with IPv4 header total length > to understand the packet has payload or not. > > The supported operations can be as below: > - RTE_FLOW_ITEM_COMPARE_EQ (equal) > - RTE_FLOW_ITEM_COMPARE_NE (not equal) > - RTE_FLOW_ITEM_COMPARE_LT (less than) > - RTE_FLOW_ITEM_COMPARE_LE (less than or equal) > - RTE_FLOW_ITEM_COMPARE_GT (great than) > - RTE_FLOW_ITEM_COMPARE_GE (great than or equal) > > V5: > - rebase on top of next-net > - add sample detail for rte_flow_field. > > V4: > - rebase on top of the latest version. > - move ACTION_MODIFY_PATTERN_SIZE and modify_field_ids rename >to first patch. > - add comparison flow create sample in testpmd_funcs.rst. > > V3: > - fix code style missing empty line in rte_flow.rst. > - fix missing the ABI change release notes. > > V2: > - Since modify field data struct is experiment, rename modify >field data directly instead of adding new flow field struct. > > > Suanming Mou (3): > ethdev: rename action modify field data structure > ethdev: add compare item > net/mlx5: add compare item support > Mostly looks good, please find comments on a few minor issues on patches.
Re: [PATCH v5 1/3] ethdev: rename action modify field data structure
On 2/1/2024 12:29 PM, Suanming Mou wrote:
> Current rte_flow_action_modify_data struct describes the pkt
> field perfectly and is used only in action.
>
> It is planned to be used for item as well. This commit renames
> it to "rte_flow_field_data" making it compatible to be used by item.
>
> Signed-off-by: Suanming Mou
> Acked-by: Ori Kam
> Acked-by: Andrew Rybchenko
<...>
> diff --git a/doc/guides/rel_notes/release_24_03.rst
> b/doc/guides/rel_notes/release_24_03.rst
> index 84d3144215..efeda6ea97 100644
> --- a/doc/guides/rel_notes/release_24_03.rst
> +++ b/doc/guides/rel_notes/release_24_03.rst
> @@ -124,6 +124,7 @@ ABI Changes
>
> * No ABI change that would break compatibility with 23.11.
>
> +* ethdev: Rename the experimental ``struct rte_flow_action_modify_data`` to
> be ``struct rte_flow_field_data``
>
Please put one more empty line after your change, to have two empty
lines before next section.
<...>
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index 1267c146e5..a143ecb194 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -3887,6 +3887,8 @@ struct rte_flow_action_ethdev {
>
> /**
> * Field IDs for MODIFY_FIELD action.
> + * e.g. the packet field IDs used in RTE_FLOW_ACTION_TYPE_MODIFY_FIELD
> + * and RTE_FLOW_ITEM_TYPE_COMPARE.
>
In this patch there is no RTE_FLOW_ITEM_TYPE_COMPARE yet, can you please
update to have RTE_FLOW_ACTION_TYPE_MODIFY_FIELD in this patch and add
RTE_FLOW_ITEM_TYPE_COMPARE in next patch?
> */
> enum rte_flow_field_id {
> RTE_FLOW_FIELD_START = 0, /**< Start of a packet. */
> @@ -3940,9 +3942,11 @@ enum rte_flow_field_id {
> * @warning
> * @b EXPERIMENTAL: this structure may change without prior notice
> *
> - * Field description for MODIFY_FIELD action.
> + * Field description for packet field.
> + * e.g. the packet fields used in RTE_FLOW_ACTION_TYPE_MODIFY_FIELD
> + * and RTE_FLOW_ITEM_TYPE_COMPARE.
>
Same here, can you please mention from RTE_FLOW_ITEM_TYPE_COMPARE in
next patch.
Re: [PATCH v5 2/3] ethdev: add compare item
On 2/1/2024 12:29 PM, Suanming Mou wrote: > Actions list > > @@ -5320,6 +5327,23 @@ A RAW rule can be created as following using > ``pattern_hex`` key and mask. > pattern_hex mask > / end actions > queue index 4 / end > > +Sample match with comparison rule > +~ > + > +Match with comparsion rule can be created as following using ``compare``. > + s/comparsion/comparison/
Re: [PATCH v5 3/3] net/mlx5: add compare item support
On 2/1/2024 12:29 PM, Suanming Mou wrote: > diff --git a/doc/guides/rel_notes/release_24_03.rst > b/doc/guides/rel_notes/release_24_03.rst > index ffceab59e4..91b2cafb00 100644 > --- a/doc/guides/rel_notes/release_24_03.rst > +++ b/doc/guides/rel_notes/release_24_03.rst > @@ -80,6 +80,8 @@ New Features >* Added support for Atomic Rules' TK242 packet-capture family of devices > with PCI IDs: ``0x1024, 0x1025, 0x1026``. > > + * Added support for comparing result between packet fields or value. > + > Above update is under 'Atomic Rule' block, I guess something went wrong during git rebase, can you please check?
[PATCH v2] doc: fix test eventdev example commands
From: Pavan Nikhilesh
Fix incorrect core masks in testeventdev example
commands.
Fixes: f6dda59153f1 ("doc: add order queue test in eventdev test guide")
Fixes: dd37027f2ba6 ("doc: add order all types queue test in eventdev test
guide")
Fixes: 43bc2fef79cd ("doc: add perf queue test in eventdev test guide")
Fixes: b3d4e665ed3d ("doc: add perf all types queue test in eventdev test
guide")
Fixes: b01974da9f25 ("app/eventdev: add ethernet device producer option")
Fixes: ba9de463abeb ("doc: add pipeline queue test in testeventdev guide")
Fixes: d1b46daf7484 ("doc: add pipeline atq test in testeventdev guide")
Fixes: d008f20bce23 ("app/eventdev: add event timer adapter as a producer")
Fixes: 2eaa37b86635 ("app/eventdev: add vector mode in pipeline test")
Cc: sta...@dpdk.org
Signed-off-by: Pavan Nikhilesh
---
doc/guides/tools/testeventdev.rst | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/doc/guides/tools/testeventdev.rst
b/doc/guides/tools/testeventdev.rst
index fc36bfb30c..5d07f6a1b1 100644
--- a/doc/guides/tools/testeventdev.rst
+++ b/doc/guides/tools/testeventdev.rst
@@ -308,7 +308,7 @@ Example command to run order queue test:
.. code-block:: console
- sudo /app/dpdk-test-eventdev --vdev=event_sw0 -- \
+ sudo /app/dpdk-test-eventdev -c 0x1f -s 0x10 --vdev=event_sw0 --
\
--test=order_queue --plcores 1 --wlcores 2,3
@@ -371,7 +371,7 @@ Example command to run order ``all types queue`` test:
.. code-block:: console
- sudo /app/dpdk-test-eventdev --vdev=event_octeontx -- \
+ sudo /app/dpdk-test-eventdev -c 0x1f --vdev=event_octeontx -- \
--test=order_atq --plcores 1 --wlcores 2,3
@@ -475,14 +475,14 @@ Example command to run perf queue test:
.. code-block:: console
- sudo /app/dpdk-test-eventdev -c 0xf -s 0x1 --vdev=event_sw0 -- \
+ sudo /app/dpdk-test-eventdev -c 0xf -s 0x2 --vdev=event_sw0 -- \
--test=perf_queue --plcores=2 --wlcore=3 --stlist=p --nb_pkts=0
Example command to run perf queue test with producer enqueuing a burst of
events:
.. code-block:: console
- sudo /app/dpdk-test-eventdev -c 0xf -s 0x1 --vdev=event_sw0 -- \
+ sudo /app/dpdk-test-eventdev -c 0xf -s 0x2 --vdev=event_sw0 -- \
--test=perf_queue --plcores=2 --wlcore=3 --stlist=p --nb_pkts=0 \
--prod_enq_burst_sz=32
@@ -490,15 +490,15 @@ Example command to run perf queue test with ethernet
ports:
.. code-block:: console
- sudo build/app/dpdk-test-eventdev --vdev=event_sw0 -- \
+ sudo build/app/dpdk-test-eventdev -c 0xf -s 0x2 --vdev=event_sw0 -- \
--test=perf_queue --plcores=2 --wlcore=3 --stlist=p --prod_type_ethdev
Example command to run perf queue test with event timer adapter:
.. code-block:: console
- sudo /app/dpdk-test-eventdev --vdev="event_octeontx" -- \
---wlcores 4 --plcores 12 --test perf_queue --stlist=a \
+ sudo /app/dpdk-test-eventdev -c 0xfff1 \
+-- --wlcores 4 --plcores 12 --test perf_queue --stlist=a \
--prod_type_timerdev --fwd_latency
PERF_ATQ Test
@@ -585,15 +585,15 @@ Example command to run perf ``all types queue`` test:
.. code-block:: console
- sudo /app/dpdk-test-eventdev --vdev=event_octeontx -- \
+ sudo /app/dpdk-test-eventdev -c 0xf --vdev=event_octeontx -- \
--test=perf_atq --plcores=2 --wlcore=3 --stlist=p --nb_pkts=0
Example command to run perf ``all types queue`` test with event timer adapter:
.. code-block:: console
- sudo /app/dpdk-test-eventdev --vdev="event_octeontx" -- \
---wlcores 4 --plcores 12 --test perf_atq --verbose 20 \
+ sudo /app/dpdk-test-eventdev -c 0xfff1 \
+-- --wlcores 4 --plcores 12 --test perf_atq --verbose 20 \
--stlist=a --prod_type_timerdev --fwd_latency
@@ -817,13 +817,13 @@ Example command to run pipeline atq test:
.. code-block:: console
-sudo /app/dpdk-test-eventdev -c 0xf -s 0x8 --vdev=event_sw0 -- \
+sudo /app/dpdk-test-eventdev -c 0xf -- \
--test=pipeline_atq --wlcore=1 --prod_type_ethdev --stlist=a
Example command to run pipeline atq test with vector events:
.. code-block:: console
-sudo /app/dpdk-test-eventdev -c 0xf -s 0x8 --vdev=event_sw0 -- \
+sudo /app/dpdk-test-eventdev -c 0xf -- \
--test=pipeline_atq --wlcore=1 --prod_type_ethdev --stlist=a \
--enable_vector --vector_size 512
--
2.25.1
