[PATCH] pdump: fix build issue with GCC 12
The following warning is observed with GCC12 compilation
with release 20.11:
In function ‘__rte_ring_enqueue_elems_64’,
inlined from ‘__rte_ring_enqueue_elems’ at
../lib/librte_ring/rte_ring_elem.h:225:3,
inlined from ‘__rte_ring_do_enqueue_elem’ at
../lib/librte_ring/rte_ring_elem.h:424:2,
inlined from ‘rte_ring_mp_enqueue_burst_elem’ at
../lib/librte_ring/rte_ring_elem.h:884:9,
inlined from ‘rte_ring_enqueue_burst_elem’ at
../lib/librte_ring/rte_ring_elem.h:946:10,
inlined from ‘rte_ring_enqueue_burst’ at
../lib/librte_ring/rte_ring.h:721:9,
inlined from ‘pdump_copy’ at
../lib/librte_pdump/rte_pdump.c:94:13:
../lib/librte_ring/rte_ring_elem.h:162:40: warning: ‘*dup_bufs.36_42
+ _89’ may be used uninitialized [-Wmaybe-uninitialized]
162 | ring[idx] = obj[i];
| ~~~^~~
../lib/librte_ring/rte_ring_elem.h:163:44: warning: ‘*dup_bufs.36_42
+ _98’ may be used uninitialized [-Wmaybe-uninitialized]
163 | ring[idx + 1] = obj[i + 1];
| ~~~^~~
../lib/librte_ring/rte_ring_elem.h:164:44: warning: ‘*dup_bufs.36_42
+ _107’ may be used uninitialized [-Wmaybe-uninitialized]
164 | ring[idx + 2] = obj[i + 2];
| ~~~^~~
../lib/librte_ring/rte_ring_elem.h:165:44: warning: ‘*dup_bufs.36_42
+ _116’ may be used uninitialized [-Wmaybe-uninitialized]
165 | ring[idx + 3] = obj[i + 3];
| ~~~^~~
../lib/librte_ring/rte_ring_elem.h:169:42: warning: ‘*dup_bufs.36_42
+ _129’ may be used uninitialized [-Wmaybe-uninitialized]
169 | ring[idx++] = obj[i++]; /* fallthrough */
| ~~~^
../lib/librte_ring/rte_ring_elem.h:171:42: warning: ‘*dup_bufs.36_42
+ _139’ may be used uninitialized [-Wmaybe-uninitialized]
171 | ring[idx++] = obj[i++]; /* fallthrough */
| ~~~^
../lib/librte_ring/rte_ring_elem.h:173:42: warning: ‘*dup_bufs.36_42
+ _149’ may be used uninitialized [-Wmaybe-uninitialized]
173 | ring[idx++] = obj[i++];
Actually, this is an alias warning as -O3 enables strict alias.
This patch fixes it by replacing 'dup_bufs' with '&dup_bufs[0]'
as the compiler represents them differently.
Fixes: 278f945402c5 ("pdump: add new library for packet capture")
Cc: sta...@dpdk.org
Signed-off-by: Joyce Kong
Reviewed-by: Ruifeng Wang
---
lib/pdump/rte_pdump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/pdump/rte_pdump.c b/lib/pdump/rte_pdump.c
index 9bc4bab4f2..53cca1034d 100644
--- a/lib/pdump/rte_pdump.c
+++ b/lib/pdump/rte_pdump.c
@@ -134,7 +134,7 @@ pdump_copy(uint16_t port_id, uint16_t queue,
__atomic_fetch_add(&stats->accepted, d_pkts, __ATOMIC_RELAXED);
- ring_enq = rte_ring_enqueue_burst(ring, (void *)dup_bufs, d_pkts, NULL);
+ ring_enq = rte_ring_enqueue_burst(ring, (void *)&dup_bufs[0], d_pkts,
NULL);
if (unlikely(ring_enq < d_pkts)) {
unsigned int drops = d_pkts - ring_enq;
--
2.25.1
RE: [PATCH] doc: fix cryptodev code block mismatch
> -Original Message-
> From: Akhil Goyal
> Sent: Tuesday 21 March 2023 13:05
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; david.march...@redhat.com;
> hemant.agra...@nxp.com; ano...@marvell.com; De Lara Guarch, Pablo
> ; Trahe, Fiona ;
> Doherty, Declan ; ma...@nvidia.com;
> g.si...@nxp.com; fanzhang@gmail.com; jianjay.z...@huawei.com;
> asoma...@amd.com; ruifeng.w...@arm.com;
> konstantin.v.anan...@yandex.ru; Nicolau, Radu ;
> ajit.khapa...@broadcom.com; rnagadhee...@marvell.com;
> adwiv...@marvell.com; Power, Ciara ; Akhil Goyal
> ; sta...@dpdk.org
> Subject: [PATCH] doc: fix cryptodev code block mismatch
>
> Certain structures were replicated in programmer's guide, which resulted in
> mismatch when that structure is changed in future releases.
> Added literal includes to copy code block while compiling.
>
> Fixes: 0318c02b57cf ("doc: add cryptodev chapter in prog guide")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Akhil Goyal
> Reported-by: David Marchand
> ---
> doc/guides/prog_guide/cryptodev_lib.rst | 121
> lib/cryptodev/rte_crypto_sym.h | 4 +
> lib/cryptodev/rte_cryptodev.h | 6 ++
> 3 files changed, 31 insertions(+), 100 deletions(-)
Acked-by: Ciara Power
RE: [PATCH] doc: fix cryptodev code block mismatch
Acked-by: Hemant Agrawal
[PATCH] net/iavf: fix VLAN offload with AVX512
It has been observed that mbufs of some received VLAN packets had the
VLAN tag correctly set in vlan_tci, but ol_flags were missing the
VLAN-indicating flags.
_mm256_shuffle_epi8 operates as two independent 128-bit operations,
not as a single 256-bit operation. To have the RTE_MBUF_F_RX_VLAN* flags
reflected in the resulting vlan_flags for all 8 rx descriptors, the
input l2tag2_flags_shuf must contain the required pattern in both
128-bit halves.
This fix is for the AVX512 Rx path. The same bug in AVX2 was fixed
by commit eb24917428a1 ("net/iavf: fix VLAN offload with AVX2").
Fixes: 4b64ccb328c9 ("net/iavf: fix VLAN extraction in AVX512 path")
Cc: sta...@dpdk.org
Signed-off-by: Michal Schmidt
---
drivers/net/iavf/iavf_rxtx_vec_avx512.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/iavf/iavf_rxtx_vec_avx512.c
b/drivers/net/iavf/iavf_rxtx_vec_avx512.c
index 4fe9b972786a..bd2788121b5a 100644
--- a/drivers/net/iavf/iavf_rxtx_vec_avx512.c
+++ b/drivers/net/iavf/iavf_rxtx_vec_avx512.c
@@ -1214,7 +1214,10 @@ _iavf_recv_raw_pkts_vec_avx512_flex_rxd(struct
iavf_rx_queue *rxq,
(0, 0, 0, 0,
0, 0, 0, 0,
0, 0, 0, 0,
-0, 0, 0, 0,
+0, 0,
+RTE_MBUF_F_RX_VLAN |
+
RTE_MBUF_F_RX_VLAN_STRIPPED,
+0,
/* end up 128-bits */
0, 0, 0, 0,
0, 0, 0, 0,
--
2.39.2
RE: [PATCH] app/flow-perf: replace RTE_BE32/16 with rte_cpu_to_be_32/16 for variables
Hi, > -Original Message- > From: Harold Huang > Sent: Sunday, March 12, 2023 4:00 AM > To: dev@dpdk.org > Cc: Harold Huang ; Wisam Monther > > Subject: [PATCH] app/flow-perf: replace RTE_BE32/16 with > rte_cpu_to_be_32/16 for variables > > In DPDK, the macros RTE_BE32 or RTE_BE16 are usually used for constant > values. And functions such as rte_cpu_to_be_32 or > rte_cpu_to_be_16 are optimized for variables. > > Signed-off-by: Harold Huang > --- > app/test-flow-perf/actions_gen.c | 28 ++-- > app/test-flow-perf/items_gen.c | 2 +- > 2 files changed, 15 insertions(+), 15 deletions(-) > Indeed your change is in the correct files and I agree that it's need to be done, But you are not doing it for all RTE_BE32 and RTE_BE16 in the app or the same files After quick search I see: app/test-flow-perf/items_gen.c:12 app/test-flow-perf/actions_gen.c:29 While you are doing the change only for: app/test-flow-perf/items_gen.c:1 app/test-flow-perf/actions_gen.c:14 Can you please extend your fix for all needed vars. BRs, Wisam Jaddo
[PATCH] doc: fix dcf instructions
Replace the deprecated VF action with the represented_port action.
Fixes: 776c119736e7 ("net/ice: remove deprecated VF flow action")
Cc: sta...@dpdk.org
Signed-off-by: Qi Zhang
---
doc/guides/nics/ice.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index 70e19c3318..f3d3540992 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -343,18 +343,18 @@ Additional Options
ip link set dev enp24s0f0 vf 0 trust on
-#. Bind the VF0, and run testpmd with 'cap=dcf' devarg::
+#. Bind the VF0, and run testpmd with 'cap=dcf' with port representor for VF 1
and 2::
- dpdk-testpmd -l 22-25 -n 4 -a 18:01.0,cap=dcf -- -i
+ dpdk-testpmd -l 22-25 -n 4 -a 18:01.0,cap=dcf,representor=vf[1-2] -- -i
#. Monitor the VF2 interface network traffic::
tcpdump -e -nn -i enp24s1f2
-#. Create one flow to redirect the traffic to VF2 by DCF::
+#. Create one flow to redirect the traffic to VF2 by DCF(assume the
representor port id is 5)::
flow create 0 priority 0 ingress pattern eth / ipv4 src is 192.168.0.2 \
- dst is 192.168.0.3 / end actions vf id 2 / end
+ dst is 192.168.0.3 / end actions represented_port ethdev_port_id 5 / end
#. Send the packet, and it should be displayed on tcpdump::
--
2.31.1
RE: [PATCH V1] doc: add tested Intel platforms with Intel NICs
> -Original Message- > From: Peng, Yuan > Sent: Friday, March 24, 2023 3:55 PM > To: Chen, LingliX ; Zhang, Qi Z > ; dev@dpdk.org > Subject: RE: [PATCH V1] doc: add tested Intel platforms with Intel NICs > > > > > -Original Message- > > From: Chen, LingliX > > Sent: Wednesday, March 22, 2023 1:52 PM > > To: Zhang, Qi Z ; dev@dpdk.org > > Cc: Peng, Yuan ; Chen, LingliX > > > > Subject: [PATCH V1] doc: add tested Intel platforms with Intel NICs > > > > Add tested Intel platforms with Intel NICs to v23.03 release note. > > > > Signed-off-by: Lingli Chen > > Acked-by: Yuan Peng Applied to dpdk-next-net-intel. Thanks Qi
x86 rte_memcpy_aligned possible optimization
Hi Bruce,
I think one of the loops in rte_memcpy_aligned() takes one too many rounds in
the case where the catch-up could replace the last round.
Consider e.g. n = 128:
The 64 bytes block copy will take two rounds, and the catch-up will copy the
last 64 bytes once again.
I think that the 64 bytes block copy could take only one round and let the
catch-up copy the last 64 bytes.
I'm not sure if my suggested method is generally faster than the current
method, so I'm passing the ball.
PS: It looks like something similar can be done for the other block copy loops
in this file. I haven't dug into the details.
static __rte_always_inline void *
rte_memcpy_aligned(void *dst, const void *src, size_t n)
{
void *ret = dst;
/* Copy size < 16 bytes */
if (n < 16) {
return rte_mov15_or_less(dst, src, n);
}
/* Copy 16 <= size <= 32 bytes */
if (n <= 32) {
rte_mov16((uint8_t *)dst, (const uint8_t *)src);
rte_mov16((uint8_t *)dst - 16 + n,
(const uint8_t *)src - 16 + n);
return ret;
}
/* Copy 32 < size <= 64 bytes */
if (n <= 64) {
rte_mov32((uint8_t *)dst, (const uint8_t *)src);
rte_mov32((uint8_t *)dst - 32 + n,
(const uint8_t *)src - 32 + n);
return ret;
}
/* Copy 64 bytes blocks */
- for (; n >= 64; n -= 64) {
+ for (; n > 64; n -= 64) {
rte_mov64((uint8_t *)dst, (const uint8_t *)src);
dst = (uint8_t *)dst + 64;
src = (const uint8_t *)src + 64;
}
/* Copy whatever left */
rte_mov64((uint8_t *)dst - 64 + n,
(const uint8_t *)src - 64 + n);
return ret;
}
Med venlig hilsen / Kind regards,
-Morten Brørup
Re: [PATCH] app/flow-perf: replace RTE_BE32/16 with rte_cpu_to_be_32/16 for variables
HI, I see all the other RTE_BE32 and RTE_BE16 are used for constant values. I think it is not necessary to fix them: In app/test-flow-perf/items_gen.c: .hdr.vlan_tci = RTE_BE16(VLAN_VALUE), .hdr.vlan_tci = RTE_BE16(0x), ipv4_masks[ti].hdr.src_addr = RTE_BE32(0x); .protocol = RTE_BE16(RTE_ETHER_TYPE_TEB), .protocol = RTE_BE16(0x), .hdr.teid = RTE_BE32(TEID_VALUE), .hdr.teid = RTE_BE32(0x), .data = RTE_BE32(META_DATA), .data = RTE_BE32(0x), .data = RTE_BE32(META_DATA), .data = RTE_BE32(0x), In app/test-flow-perf/actions_gen.c: .data = RTE_BE32(META_DATA), .mask = RTE_BE32(0x), .data = RTE_BE32(META_DATA), .mask = RTE_BE32(0x), eth_hdr.ether_type = RTE_BE16(RTE_ETHER_TYPE_VLAN); eth_hdr.ether_type = RTE_BE16(RTE_ETHER_TYPE_IPV4); eth_hdr.ether_type = RTE_BE16(RTE_ETHER_TYPE_IPV6); vlan_hdr.eth_proto = RTE_BE16(RTE_ETHER_TYPE_IPV4); vlan_hdr.eth_proto = RTE_BE16(RTE_ETHER_TYPE_IPV6); udp_hdr.dst_port = RTE_BE16(RTE_VXLAN_DEFAULT_PORT); udp_hdr.dst_port = RTE_BE16(RTE_VXLAN_GPE_UDP_PORT); udp_hdr.dst_port = RTE_BE16(RTE_GENEVE_UDP_PORT); udp_hdr.dst_port = RTE_BE16(RTE_GTPU_UDP_PORT); gre_hdr.proto = RTE_BE16(RTE_ETHER_TYPE_TEB); item_udp.hdr.dst_port = RTE_BE16(RTE_VXLAN_DEFAULT_PORT); On Mon, Mar 27, 2023 at 6:29 PM Wisam Monther wrote: > > Hi, > > > -Original Message- > > From: Harold Huang > > Sent: Sunday, March 12, 2023 4:00 AM > > To: dev@dpdk.org > > Cc: Harold Huang ; Wisam Monther > > > > Subject: [PATCH] app/flow-perf: replace RTE_BE32/16 with > > rte_cpu_to_be_32/16 for variables > > > > In DPDK, the macros RTE_BE32 or RTE_BE16 are usually used for constant > > values. And functions such as rte_cpu_to_be_32 or > > rte_cpu_to_be_16 are optimized for variables. > > > > Signed-off-by: Harold Huang > > --- > > app/test-flow-perf/actions_gen.c | 28 ++-- > > app/test-flow-perf/items_gen.c | 2 +- > > 2 files changed, 15 insertions(+), 15 deletions(-) > > > > Indeed your change is in the correct files and I agree that it's need to be > done, > But you are not doing it for all RTE_BE32 and RTE_BE16 in the app or the same > files > > After quick search I see: > app/test-flow-perf/items_gen.c:12 > app/test-flow-perf/actions_gen.c:29 > > While you are doing the change only for: > app/test-flow-perf/items_gen.c:1 > app/test-flow-perf/actions_gen.c:14 > > Can you please extend your fix for all needed vars. > > BRs, > Wisam Jaddo -- Thanks, Harold.
Re: [PATCH v3] net/iavf: fix iavf query stats in intr thread
On 3/27/2023 6:31 AM, Deng, KaiwenX wrote:
>
>
>> -Original Message-
>> From: Ferruh Yigit
>> Sent: Thursday, March 23, 2023 11:39 PM
>> To: Deng, KaiwenX ; dev@dpdk.org
>> Cc: sta...@dpdk.org; Yang, Qiming ; Zhou, YidingX
>> ; Chas Williams ; Min Hu (Connor)
>> ; Wu, Jingjing ; Xing, Beilei
>> ; Mike Pattrick ; Zhang, Qi Z
>> ; Doherty, Declan ;
>> Mrzyglod, Daniel T ; Dapeng Yu
>>
>> Subject: Re: [PATCH v3] net/iavf: fix iavf query stats in intr thread
>>
>> On 3/22/2023 7:26 AM, Kaiwen Deng wrote:
>>> When iavf send query-stats command in eal-intr-thread through virtual
>>> channel, there will be no response received from
>>> iavf_dev_virtchnl_handler for this command during block and wait.
>>> Because iavf_dev_virtchnl_handler is also registered in eal-intr-thread.
>>>
>>> When vf device is bonded as BONDING_MODE_TLB mode, the slave device
>>> update callback will registered in alarm and called by
>>> eal-intr-thread, it would also raise the above issue.
>>>
>>> This commit add to poll the response for VIRTCHNL_OP_GET_STATS when
>> it
>>> is called by eal-intr-thread to fix this issue.
>>>
>>> Fixes: 91bf37d250aa ("net/iavf: add lock for VF commands")
>>> Fixes: 22b123a36d07 ("net/avf: initialize PMD")
>>> Fixes: 7c76a747e68c ("bond: add mode 5")
>>> Fixes: 435d523112cc ("net/iavf: fix multi-process shared data")
>>> Fixes: cb5c1b91f76f ("net/iavf: add thread for event callbacks")
>>
>>
>> Hi Kaiwen,
>>
>> Above commit already seems trying to address same issue, it creates "iavf-
>> event-thread" control thread to asyncroniously handle the interrupts, in non-
>> interrupt context, why it is not working?
>>
>> Instead of adding 'rte_thread_is_intr()' checks, can't you make sure all
>> interrupts handled in control tread?
>>
>> And can you please provide a stack trace in commit log, to describe the issue
>> better?
> Hi Ferru,
> Sorry for my late reply, And thanks for your review.
>
> The above commit does not fix this issue when we need to get the returned
> data.
> If we call iavf_query_stats and wait for response statistics in the
> intr-thread.
> iavf_handle_virtchnl_msg is also registered in the intr_thread and will not
> be
> executed while waiting.
>
Got it, since return value is required, API can't be called asyncroniously.
I think 'rte_thread_is_intr()' checks may cause more trouble for you in
long term,
- why 'iavf_query_stats()' is called in the iterrupt thread, can it be
prevented?
- does it make sense to allways poll messages from PF (for simplification)?
If answer to both are 'No', I am OK to continue with current proposal if
you are happy with it.
> This commit I changed it to polling for replies to commands executed in the
> interrupt thread.
>
> main thread
> interrupt thread
> |
>|
> |
>|
> iavf_query_stats
> |
> iavf_execute_vf_cmd
> |
> iavf_aq_send_msg_to_pf and wait handle complete
> |
> |
> |
>
> |>|
> |
> |
> |
>iavf_handle_virtchnl_msg
> |
> |
>
> |<|
> |
> |
> iavf_execute_vf_cmd get response
> |
> |
> |
>
> The above is the stack trace for the normal execution of iavf_query_stats
> in the main thread.
>
> interrupt thread
> |
> |
> iavf_query_stats
> iavf_execute_vf_cmd
> iavf_aq_send_msg_to_pf wait handle complete(1 sec)
> iavf_execute_vf_cmd timeout
> |
> |
> iavf_handle_virtchnl_msg
> |
>
> The above is the stack trace
Re: [PATCH v3] net/iavf: fix iavf query stats in intr thread
On 3/27/2023 1:31 PM, Ferruh Yigit wrote:
> On 3/27/2023 6:31 AM, Deng, KaiwenX wrote:
>>
>>
>>> -Original Message-
>>> From: Ferruh Yigit
>>> Sent: Thursday, March 23, 2023 11:39 PM
>>> To: Deng, KaiwenX ; dev@dpdk.org
>>> Cc: sta...@dpdk.org; Yang, Qiming ; Zhou, YidingX
>>> ; Chas Williams ; Min Hu (Connor)
>>> ; Wu, Jingjing ; Xing, Beilei
>>> ; Mike Pattrick ; Zhang, Qi Z
>>> ; Doherty, Declan ;
>>> Mrzyglod, Daniel T ; Dapeng Yu
>>>
>>> Subject: Re: [PATCH v3] net/iavf: fix iavf query stats in intr thread
>>>
>>> On 3/22/2023 7:26 AM, Kaiwen Deng wrote:
When iavf send query-stats command in eal-intr-thread through virtual
channel, there will be no response received from
iavf_dev_virtchnl_handler for this command during block and wait.
Because iavf_dev_virtchnl_handler is also registered in eal-intr-thread.
When vf device is bonded as BONDING_MODE_TLB mode, the slave device
update callback will registered in alarm and called by
eal-intr-thread, it would also raise the above issue.
This commit add to poll the response for VIRTCHNL_OP_GET_STATS when
>>> it
is called by eal-intr-thread to fix this issue.
Fixes: 91bf37d250aa ("net/iavf: add lock for VF commands")
Fixes: 22b123a36d07 ("net/avf: initialize PMD")
Fixes: 7c76a747e68c ("bond: add mode 5")
Fixes: 435d523112cc ("net/iavf: fix multi-process shared data")
Fixes: cb5c1b91f76f ("net/iavf: add thread for event callbacks")
>>>
>>>
>>> Hi Kaiwen,
>>>
>>> Above commit already seems trying to address same issue, it creates "iavf-
>>> event-thread" control thread to asyncroniously handle the interrupts, in
>>> non-
>>> interrupt context, why it is not working?
>>>
>>> Instead of adding 'rte_thread_is_intr()' checks, can't you make sure all
>>> interrupts handled in control tread?
>>>
>>> And can you please provide a stack trace in commit log, to describe the
>>> issue
>>> better?
>> Hi Ferru,
>> Sorry for my late reply, And thanks for your review.
>>
>> The above commit does not fix this issue when we need to get the returned
>> data.
>> If we call iavf_query_stats and wait for response statistics in the
>> intr-thread.
>> iavf_handle_virtchnl_msg is also registered in the intr_thread and will not
>> be
>> executed while waiting.
>>
>
> Got it, since return value is required, API can't be called asyncroniously.
>
>
>
> I think 'rte_thread_is_intr()' checks may cause more trouble for you in
> long term,
>
> - why 'iavf_query_stats()' is called in the iterrupt thread, can it be
> prevented?
>
> - does it make sense to allways poll messages from PF (for simplification)?
>
>
> If answer to both are 'No', I am OK to continue with current proposal if
> you are happy with it.
>
btw, how critical is this issue?
If it is critical, I am OK to get it as it is for this release and
investigate it further for next release, since only a few days left for
this release.
>
>> This commit I changed it to polling for replies to commands executed in the
>> interrupt thread.
>>
>> main thread
>> interrupt thread
>> |
>> |
>> |
>> |
>> iavf_query_stats
>>|
>> iavf_execute_vf_cmd
>> |
>> iavf_aq_send_msg_to_pf and wait handle complete
>> |
>> |
>>|
>>
>> |>|
>> |
>>|
>> |
>> iavf_handle_virtchnl_msg
>> |
>> |
>>
>> |<|
>> |
>> |
>> iavf_execute_vf_cmd get response
>> |
>> |
>>
[PATCH] vhost: add device op to offload the interrupt kick
This patch adds an operation callback which gets called every time the
library wants to call eventfd_write(). This eventfd_write() call could
result in a system call, which could potentially block the PMD thread.
The callback function can decide whether it's ok to handle the
eventfd_write() now or have the newly introduced function,
rte_vhost_notify_guest(), called at a later time.
This can be used by 3rd party applications, like OVS, to avoid system
calls being called as part of the PMD threads.
Signed-off-by: Eelco Chaudron
---
lib/vhost/rte_vhost.h | 10 +-
lib/vhost/vhost.c | 21 +
lib/vhost/vhost.h | 43 ---
3 files changed, 58 insertions(+), 16 deletions(-)
diff --git a/lib/vhost/rte_vhost.h b/lib/vhost/rte_vhost.h
index 58a5d4be92..af7a394d0f 100644
--- a/lib/vhost/rte_vhost.h
+++ b/lib/vhost/rte_vhost.h
@@ -298,7 +298,13 @@ struct rte_vhost_device_ops {
*/
void (*guest_notified)(int vid);
- void *reserved[1]; /**< Reserved for future extension */
+ /**
+* If this callback is registered, notification to the guest can
+* be handled by the front-end calling rte_vhost_notify_guest().
+* If it's not handled, 'false' should be returned. This can be used
+* to remove the "slow" eventfd_write() syscall from the datapath.
+*/
+ bool (*guest_notify)(int vid, uint16_t queue_id);
};
/**
@@ -433,6 +439,8 @@ void rte_vhost_log_used_vring(int vid, uint16_t vring_idx,
int rte_vhost_enable_guest_notification(int vid, uint16_t queue_id, int
enable);
+void rte_vhost_notify_guest(int vid, uint16_t queue_id);
+
/**
* Register vhost driver. path could be different for multiple
* instance support.
diff --git a/lib/vhost/vhost.c b/lib/vhost/vhost.c
index ef37943817..ee090d78ef 100644
--- a/lib/vhost/vhost.c
+++ b/lib/vhost/vhost.c
@@ -1467,6 +1467,27 @@ rte_vhost_enable_guest_notification(int vid, uint16_t
queue_id, int enable)
return ret;
}
+void
+rte_vhost_notify_guest(int vid, uint16_t queue_id)
+{
+ struct virtio_net *dev = get_device(vid);
+ struct vhost_virtqueue *vq;
+
+ if (!dev || queue_id >= VHOST_MAX_VRING)
+ return;
+
+ vq = dev->virtqueue[queue_id];
+ if (!vq)
+ return;
+
+ rte_spinlock_lock(&vq->access_lock);
+
+ if (vq->callfd >= 0)
+ eventfd_write(vq->callfd, (eventfd_t)1);
+
+ rte_spinlock_unlock(&vq->access_lock);
+}
+
void
rte_vhost_log_write(int vid, uint64_t addr, uint64_t len)
{
diff --git a/lib/vhost/vhost.h b/lib/vhost/vhost.h
index 8fdab13c70..39ad8260a1 100644
--- a/lib/vhost/vhost.h
+++ b/lib/vhost/vhost.h
@@ -883,6 +883,30 @@ vhost_need_event(uint16_t event_idx, uint16_t new_idx,
uint16_t old)
return (uint16_t)(new_idx - event_idx - 1) < (uint16_t)(new_idx - old);
}
+static __rte_always_inline void
+vhost_vring_kick_guest(struct virtio_net *dev, struct vhost_virtqueue *vq)
+{
+ if (dev->notify_ops->guest_notify) {
+ uint16_t qid;
+ for (qid = 0; qid < dev->nr_vring; qid++) {
+ if (dev->virtqueue[qid] == vq) {
+ if (dev->notify_ops->guest_notify(dev->vid,
+ qid))
+ goto done;
+ break;
+ }
+ }
+ }
+ eventfd_write(vq->callfd, (eventfd_t) 1);
+
+done:
+ if (dev->flags & VIRTIO_DEV_STATS_ENABLED)
+ vq->stats.guest_notifications++;
+ if (dev->notify_ops->guest_notified)
+ dev->notify_ops->guest_notified(dev->vid);
+}
+
+
static __rte_always_inline void
vhost_vring_call_split(struct virtio_net *dev, struct vhost_virtqueue *vq)
{
@@ -905,21 +929,13 @@ vhost_vring_call_split(struct virtio_net *dev, struct
vhost_virtqueue *vq)
if ((vhost_need_event(vhost_used_event(vq), new, old) &&
(vq->callfd >= 0)) ||
unlikely(!signalled_used_valid)) {
- eventfd_write(vq->callfd, (eventfd_t) 1);
- if (dev->flags & VIRTIO_DEV_STATS_ENABLED)
- vq->stats.guest_notifications++;
- if (dev->notify_ops->guest_notified)
- dev->notify_ops->guest_notified(dev->vid);
+ vhost_vring_kick_guest(dev, vq);
}
} else {
/* Kick the guest if necessary. */
if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
&& (vq->callfd >= 0)) {
- eventfd_write(vq->callfd, (eventfd_t)1);
- if (dev->flags & VIRTIO_DEV_STATS_ENABLED)
- vq->stats.guest_notifications++
Re: [PATCH] vhost: add device op to offload the interrupt kick
Hi Eelco,
On 3/27/23 14:51, Eelco Chaudron wrote:
This patch adds an operation callback which gets called every time the
library wants to call eventfd_write(). This eventfd_write() call could
result in a system call, which could potentially block the PMD thread.
The callback function can decide whether it's ok to handle the
eventfd_write() now or have the newly introduced function,
rte_vhost_notify_guest(), called at a later time.
This can be used by 3rd party applications, like OVS, to avoid system
calls being called as part of the PMD threads.
That's a good idea, please find some comments inline:
Signed-off-by: Eelco Chaudron
---
lib/vhost/rte_vhost.h | 10 +-
lib/vhost/vhost.c | 21 +
lib/vhost/vhost.h | 43 ---
3 files changed, 58 insertions(+), 16 deletions(-)
diff --git a/lib/vhost/rte_vhost.h b/lib/vhost/rte_vhost.h
index 58a5d4be92..af7a394d0f 100644
--- a/lib/vhost/rte_vhost.h
+++ b/lib/vhost/rte_vhost.h
@@ -298,7 +298,13 @@ struct rte_vhost_device_ops {
*/
void (*guest_notified)(int vid);
- void *reserved[1]; /**< Reserved for future extension */
+ /**
+* If this callback is registered, notification to the guest can
+* be handled by the front-end calling rte_vhost_notify_guest().
+* If it's not handled, 'false' should be returned. This can be used
+* to remove the "slow" eventfd_write() syscall from the datapath.
+*/
+ bool (*guest_notify)(int vid, uint16_t queue_id);
};
/**
@@ -433,6 +439,8 @@ void rte_vhost_log_used_vring(int vid, uint16_t vring_idx,
int rte_vhost_enable_guest_notification(int vid, uint16_t queue_id, int enable);
+void rte_vhost_notify_guest(int vid, uint16_t queue_id);
The new API needs to be tagged as experimental, and also documented. (I
see rte_vhost_enable_guest_notification is not properly documented, so
not a good example!)
+
/**
* Register vhost driver. path could be different for multiple
* instance support.
diff --git a/lib/vhost/vhost.c b/lib/vhost/vhost.c
index ef37943817..ee090d78ef 100644
--- a/lib/vhost/vhost.c
+++ b/lib/vhost/vhost.c
@@ -1467,6 +1467,27 @@ rte_vhost_enable_guest_notification(int vid, uint16_t
queue_id, int enable)
return ret;
}
+void
+rte_vhost_notify_guest(int vid, uint16_t queue_id)
+{
+ struct virtio_net *dev = get_device(vid);
+ struct vhost_virtqueue *vq;
+
+ if (!dev || queue_id >= VHOST_MAX_VRING)
+ return;
+
+ vq = dev->virtqueue[queue_id];
+ if (!vq)
+ return;
+
+ rte_spinlock_lock(&vq->access_lock);
+
+ if (vq->callfd >= 0)
+ eventfd_write(vq->callfd, (eventfd_t)1);
Maybe we should return an error of callfd is invalid or eventfd_write()
failed.
+
+ rte_spinlock_unlock(&vq->access_lock);
+}
+
void
rte_vhost_log_write(int vid, uint64_t addr, uint64_t len)
{
diff --git a/lib/vhost/vhost.h b/lib/vhost/vhost.h
index 8fdab13c70..39ad8260a1 100644
--- a/lib/vhost/vhost.h
+++ b/lib/vhost/vhost.h
@@ -883,6 +883,30 @@ vhost_need_event(uint16_t event_idx, uint16_t new_idx,
uint16_t old)
return (uint16_t)(new_idx - event_idx - 1) < (uint16_t)(new_idx - old);
}
+static __rte_always_inline void
+vhost_vring_kick_guest(struct virtio_net *dev, struct vhost_virtqueue *vq)
+{
+ if (dev->notify_ops->guest_notify) {
+ uint16_t qid;
+ for (qid = 0; qid < dev->nr_vring; qid++) {
+ if (dev->virtqueue[qid] == vq) {
+ if (dev->notify_ops->guest_notify(dev->vid,
+ qid))
+ goto done;
+ break;
+ }
+ }
Since v22.11, you no more need to iterate through the port's virtqueues,
David introduced index field in vhost_virtuqueue in v22.11 (57e414e3ec29
("vhost: keep a reference to virtqueue index")).
+ }
+ eventfd_write(vq->callfd, (eventfd_t) 1);
+
+done:
+ if (dev->flags & VIRTIO_DEV_STATS_ENABLED)
+ vq->stats.guest_notifications++;
+ if (dev->notify_ops->guest_notified)
+ dev->notify_ops->guest_notified(dev->vid);
+}
FYI, I have done almost the same refactoring in the VDUSE series I will
soon send:
https://gitlab.com/mcoquelin/dpdk-next-virtio/-/commit/7089a8a6d1e89b9db90547eb5b4fef886f24fd5b
My version also introduces a new counter in case the notification
failed. Maybe we could also have a counter in case the notification has
been "offloaded" to the application?
+
+
static __rte_always_inline void
vhost_vring_call_split(struct virtio_net *dev, struct vhost_virtqueue *vq)
{
@@ -905,21 +929,13 @@ vhost_vring_call_split(struct virtio_net *dev, struct
vhost_virtqueue *vq)
if ((vhost_need_event(vhost_used_event(v
Re: [PATCH] vhost: add device op to offload the interrupt kick
On 27 Mar 2023, at 15:21, Maxime Coquelin wrote:
> Hi Eelco,
>
> On 3/27/23 14:51, Eelco Chaudron wrote:
>> This patch adds an operation callback which gets called every time the
>> library wants to call eventfd_write(). This eventfd_write() call could
>> result in a system call, which could potentially block the PMD thread.
>>
>> The callback function can decide whether it's ok to handle the
>> eventfd_write() now or have the newly introduced function,
>> rte_vhost_notify_guest(), called at a later time.
>>
>> This can be used by 3rd party applications, like OVS, to avoid system
>> calls being called as part of the PMD threads.
>
> That's a good idea, please find some comments inline:
Thanks for the review, see inline.
>
>> Signed-off-by: Eelco Chaudron
>> ---
>> lib/vhost/rte_vhost.h | 10 +-
>> lib/vhost/vhost.c | 21 +
>> lib/vhost/vhost.h | 43 ---
>> 3 files changed, 58 insertions(+), 16 deletions(-)
>>
>> diff --git a/lib/vhost/rte_vhost.h b/lib/vhost/rte_vhost.h
>> index 58a5d4be92..af7a394d0f 100644
>> --- a/lib/vhost/rte_vhost.h
>> +++ b/lib/vhost/rte_vhost.h
>> @@ -298,7 +298,13 @@ struct rte_vhost_device_ops {
>> */
>> void (*guest_notified)(int vid);
>> - void *reserved[1]; /**< Reserved for future extension */
>> +/**
>> + * If this callback is registered, notification to the guest can
>> + * be handled by the front-end calling rte_vhost_notify_guest().
>> + * If it's not handled, 'false' should be returned. This can be used
>> + * to remove the "slow" eventfd_write() syscall from the datapath.
>> + */
>> +bool (*guest_notify)(int vid, uint16_t queue_id);
>> };
>>/**
>> @@ -433,6 +439,8 @@ void rte_vhost_log_used_vring(int vid, uint16_t
>> vring_idx,
>>int rte_vhost_enable_guest_notification(int vid, uint16_t queue_id, int
>> enable);
>> +void rte_vhost_notify_guest(int vid, uint16_t queue_id);
>
> The new API needs to be tagged as experimental, and also documented. (I
> see rte_vhost_enable_guest_notification is not properly documented, so
> not a good example!)
I used exactly that as an example, so thought it should be good ;)
Will add this in the next revision...
>> +
>> /**
>>* Register vhost driver. path could be different for multiple
>>* instance support.
>> diff --git a/lib/vhost/vhost.c b/lib/vhost/vhost.c
>> index ef37943817..ee090d78ef 100644
>> --- a/lib/vhost/vhost.c
>> +++ b/lib/vhost/vhost.c
>> @@ -1467,6 +1467,27 @@ rte_vhost_enable_guest_notification(int vid, uint16_t
>> queue_id, int enable)
>> return ret;
>> }
>> +void
>> +rte_vhost_notify_guest(int vid, uint16_t queue_id)
>> +{
>> +struct virtio_net *dev = get_device(vid);
>> +struct vhost_virtqueue *vq;
>> +
>> +if (!dev || queue_id >= VHOST_MAX_VRING)
>> +return;
>> +
>> +vq = dev->virtqueue[queue_id];
>> +if (!vq)
>> +return;
>> +
>> +rte_spinlock_lock(&vq->access_lock);
>> +
>> +if (vq->callfd >= 0)
>> +eventfd_write(vq->callfd, (eventfd_t)1);
>
> Maybe we should return an error of callfd is invalid or eventfd_write()
> failed.
See below
>> +
>> +rte_spinlock_unlock(&vq->access_lock);
>> +}
>> +
>> void
>> rte_vhost_log_write(int vid, uint64_t addr, uint64_t len)
>> {
>> diff --git a/lib/vhost/vhost.h b/lib/vhost/vhost.h
>> index 8fdab13c70..39ad8260a1 100644
>> --- a/lib/vhost/vhost.h
>> +++ b/lib/vhost/vhost.h
>> @@ -883,6 +883,30 @@ vhost_need_event(uint16_t event_idx, uint16_t new_idx,
>> uint16_t old)
>> return (uint16_t)(new_idx - event_idx - 1) < (uint16_t)(new_idx - old);
>> }
>> +static __rte_always_inline void
>> +vhost_vring_kick_guest(struct virtio_net *dev, struct vhost_virtqueue *vq)
>> +{
>> +if (dev->notify_ops->guest_notify) {
>> +uint16_t qid;
>> +for (qid = 0; qid < dev->nr_vring; qid++) {
>> +if (dev->virtqueue[qid] == vq) {
>> +if (dev->notify_ops->guest_notify(dev->vid,
>> + qid))
>> +goto done;
>> +break;
>> +}
>> +}
>
> Since v22.11, you no more need to iterate through the port's virtqueues,
> David introduced index field in vhost_virtuqueue in v22.11 (57e414e3ec29
> ("vhost: keep a reference to virtqueue index")).
Thanks will change this, I did most of this a while back and did not re-check.
>> +}
>> +eventfd_write(vq->callfd, (eventfd_t) 1);
>> +
>> +done:
>> +if (dev->flags & VIRTIO_DEV_STATS_ENABLED)
>> +vq->stats.guest_notifications++;
>> +if (dev->notify_ops->guest_notified)
>> +dev->notify_ops->guest_notified(dev->vid);
>> +}
>
> FYI, I have done almost the same refactoring in the VDUSE series I will
> soon send:
>
> https://gitlab.com/mcoquelin/dpdk-next-virtio/-/com
RE: [PATCH] pdump: fix build issue with GCC 12
> -Original Message- > From: Joyce Kong > Signed-off-by: Joyce Kong > Reviewed-by: Ruifeng Wang Acked-by: Reshma Pattan
[PATCH 0/3] use C11 memory model GCC builtin atomics
Replace the use of __sync__and_fetch and __sync_fetch_and_ atomics with GCC C11 memory model __atomic builtins. This series contributes to converging on standard atomics in 23.11 but is kept separate as there may be sensitivity to converting from __sync to the C11 memory model builtins. Tyler Retzlaff (3): bus/vmbus: use C11 memory model GCC builtin atomics crypto/ccp: use C11 memory model GCC builtin atomics eal: use C11 memory model GCC builtin atomics drivers/bus/vmbus/vmbus_channel.c| 2 +- drivers/crypto/ccp/ccp_dev.c | 6 -- lib/eal/include/generic/rte_atomic.h | 32 3 files changed, 21 insertions(+), 19 deletions(-) -- 1.8.3.1
[PATCH 2/3] crypto/ccp: use C11 memory model GCC builtin atomics
Replace use of __sync_fetch_and_or and __sync_fetch_and_and with
__atomic_fetch_or and __atomic_fetch_and.
Signed-off-by: Tyler Retzlaff
---
drivers/crypto/ccp/ccp_dev.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/ccp/ccp_dev.c b/drivers/crypto/ccp/ccp_dev.c
index ee30f5a..b7ca3af 100644
--- a/drivers/crypto/ccp/ccp_dev.c
+++ b/drivers/crypto/ccp/ccp_dev.c
@@ -116,13 +116,15 @@ struct ccp_queue *
static inline void
ccp_set_bit(unsigned long *bitmap, int n)
{
- __sync_fetch_and_or(&bitmap[WORD_OFFSET(n)], (1UL << BIT_OFFSET(n)));
+ __atomic_fetch_or(&bitmap[WORD_OFFSET(n)], (1UL << BIT_OFFSET(n)),
+ __ATOMIC_SEQ_CST);
}
static inline void
ccp_clear_bit(unsigned long *bitmap, int n)
{
- __sync_fetch_and_and(&bitmap[WORD_OFFSET(n)], ~(1UL << BIT_OFFSET(n)));
+ __atomic_fetch_and(&bitmap[WORD_OFFSET(n)], ~(1UL << BIT_OFFSET(n)),
+ __ATOMIC_SEQ_CST);
}
static inline uint32_t
--
1.8.3.1
[PATCH 1/3] bus/vmbus: use C11 memory model GCC builtin atomics
Replace use of __sync_or_and_fetch with __atomic_fetch_or.
Signed-off-by: Tyler Retzlaff
---
drivers/bus/vmbus/vmbus_channel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/vmbus/vmbus_channel.c
b/drivers/bus/vmbus/vmbus_channel.c
index 5549fd0..4d74df3 100644
--- a/drivers/bus/vmbus/vmbus_channel.c
+++ b/drivers/bus/vmbus/vmbus_channel.c
@@ -22,7 +22,7 @@
vmbus_sync_set_bit(volatile uint32_t *addr, uint32_t mask)
{
/* Use GCC builtin which atomic does atomic OR operation */
- __sync_or_and_fetch(addr, mask);
+ __atomic_fetch_or(addr, mask, __ATOMIC_SEQ_CST);
}
static inline void
--
1.8.3.1
[PATCH 3/3] eal: use C11 memory model GCC builtin atomics
Replace use of __sync_fetch_and_add and __sync_fetch_and_sub with
__atomic_fetch_add and __atomic_fetch_sub.
Signed-off-by: Tyler Retzlaff
---
lib/eal/include/generic/rte_atomic.h | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/lib/eal/include/generic/rte_atomic.h
b/lib/eal/include/generic/rte_atomic.h
index 234b268..58df843 100644
--- a/lib/eal/include/generic/rte_atomic.h
+++ b/lib/eal/include/generic/rte_atomic.h
@@ -243,7 +243,7 @@
static inline void
rte_atomic16_add(rte_atomic16_t *v, int16_t inc)
{
- __sync_fetch_and_add(&v->cnt, inc);
+ __atomic_fetch_add(&v->cnt, inc, __ATOMIC_SEQ_CST);
}
/**
@@ -257,7 +257,7 @@
static inline void
rte_atomic16_sub(rte_atomic16_t *v, int16_t dec)
{
- __sync_fetch_and_sub(&v->cnt, dec);
+ __atomic_fetch_sub(&v->cnt, dec, __ATOMIC_SEQ_CST);
}
/**
@@ -310,7 +310,7 @@
static inline int16_t
rte_atomic16_add_return(rte_atomic16_t *v, int16_t inc)
{
- return __sync_add_and_fetch(&v->cnt, inc);
+ return __atomic_fetch_add(&v->cnt, inc, __ATOMIC_SEQ_CST) + inc;
}
/**
@@ -330,7 +330,7 @@
static inline int16_t
rte_atomic16_sub_return(rte_atomic16_t *v, int16_t dec)
{
- return __sync_sub_and_fetch(&v->cnt, dec);
+ return __atomic_fetch_sub(&v->cnt, dec, __ATOMIC_SEQ_CST) - dec;
}
/**
@@ -349,7 +349,7 @@
#ifdef RTE_FORCE_INTRINSICS
static inline int rte_atomic16_inc_and_test(rte_atomic16_t *v)
{
- return __sync_add_and_fetch(&v->cnt, 1) == 0;
+ return __atomic_fetch_add(&v->cnt, 1, __ATOMIC_SEQ_CST) + 1 == 0;
}
#endif
@@ -369,7 +369,7 @@ static inline int rte_atomic16_inc_and_test(rte_atomic16_t
*v)
#ifdef RTE_FORCE_INTRINSICS
static inline int rte_atomic16_dec_and_test(rte_atomic16_t *v)
{
- return __sync_sub_and_fetch(&v->cnt, 1) == 0;
+ return __atomic_fetch_sub(&v->cnt, 1, __ATOMIC_SEQ_CST) - 1 == 0;
}
#endif
@@ -522,7 +522,7 @@ static inline void rte_atomic16_clear(rte_atomic16_t *v)
static inline void
rte_atomic32_add(rte_atomic32_t *v, int32_t inc)
{
- __sync_fetch_and_add(&v->cnt, inc);
+ __atomic_fetch_add(&v->cnt, inc, __ATOMIC_SEQ_CST);
}
/**
@@ -536,7 +536,7 @@ static inline void rte_atomic16_clear(rte_atomic16_t *v)
static inline void
rte_atomic32_sub(rte_atomic32_t *v, int32_t dec)
{
- __sync_fetch_and_sub(&v->cnt, dec);
+ __atomic_fetch_sub(&v->cnt, dec, __ATOMIC_SEQ_CST);
}
/**
@@ -589,7 +589,7 @@ static inline void rte_atomic16_clear(rte_atomic16_t *v)
static inline int32_t
rte_atomic32_add_return(rte_atomic32_t *v, int32_t inc)
{
- return __sync_add_and_fetch(&v->cnt, inc);
+ return __atomic_fetch_add(&v->cnt, inc, __ATOMIC_SEQ_CST) + inc;
}
/**
@@ -609,7 +609,7 @@ static inline void rte_atomic16_clear(rte_atomic16_t *v)
static inline int32_t
rte_atomic32_sub_return(rte_atomic32_t *v, int32_t dec)
{
- return __sync_sub_and_fetch(&v->cnt, dec);
+ return __atomic_fetch_sub(&v->cnt, dec, __ATOMIC_SEQ_CST) - dec;
}
/**
@@ -628,7 +628,7 @@ static inline void rte_atomic16_clear(rte_atomic16_t *v)
#ifdef RTE_FORCE_INTRINSICS
static inline int rte_atomic32_inc_and_test(rte_atomic32_t *v)
{
- return __sync_add_and_fetch(&v->cnt, 1) == 0;
+ return __atomic_fetch_add(&v->cnt, 1, __ATOMIC_SEQ_CST) + 1 == 0;
}
#endif
@@ -648,7 +648,7 @@ static inline int rte_atomic32_inc_and_test(rte_atomic32_t
*v)
#ifdef RTE_FORCE_INTRINSICS
static inline int rte_atomic32_dec_and_test(rte_atomic32_t *v)
{
- return __sync_sub_and_fetch(&v->cnt, 1) == 0;
+ return __atomic_fetch_sub(&v->cnt, 1, __ATOMIC_SEQ_CST) - 1 == 0;
}
#endif
@@ -854,7 +854,7 @@ static inline void rte_atomic32_clear(rte_atomic32_t *v)
static inline void
rte_atomic64_add(rte_atomic64_t *v, int64_t inc)
{
- __sync_fetch_and_add(&v->cnt, inc);
+ __atomic_fetch_add(&v->cnt, inc, __ATOMIC_SEQ_CST);
}
#endif
@@ -873,7 +873,7 @@ static inline void rte_atomic32_clear(rte_atomic32_t *v)
static inline void
rte_atomic64_sub(rte_atomic64_t *v, int64_t dec)
{
- __sync_fetch_and_sub(&v->cnt, dec);
+ __atomic_fetch_sub(&v->cnt, dec, __ATOMIC_SEQ_CST);
}
#endif
@@ -931,7 +931,7 @@ static inline void rte_atomic32_clear(rte_atomic32_t *v)
static inline int64_t
rte_atomic64_add_return(rte_atomic64_t *v, int64_t inc)
{
- return __sync_add_and_fetch(&v->cnt, inc);
+ return __atomic_fetch_add(&v->cnt, inc, __ATOMIC_SEQ_CST) + inc;
}
#endif
@@ -955,7 +955,7 @@ static inline void rte_atomic32_clear(rte_atomic32_t *v)
static inline int64_t
rte_atomic64_sub_return(rte_atomic64_t *v, int64_t dec)
{
- return __sync_sub_and_fetch(&v->cnt, dec);
+ return __atomic_fetch_sub(&v->cnt, dec, __ATOMIC_SEQ_CST) - dec;
}
#endif
--
1.8.3.1
Re: [PATCH] pdump: fix build issue with GCC 12
On Mon, Mar 27, 2023 at 07:07:12AM +, Joyce Kong wrote:
> The following warning is observed with GCC12 compilation
> with release 20.11:
>
> In function ‘__rte_ring_enqueue_elems_64’,
> inlined from ‘__rte_ring_enqueue_elems’ at
> ../lib/librte_ring/rte_ring_elem.h:225:3,
> inlined from ‘__rte_ring_do_enqueue_elem’ at
> ../lib/librte_ring/rte_ring_elem.h:424:2,
> inlined from ‘rte_ring_mp_enqueue_burst_elem’ at
> ../lib/librte_ring/rte_ring_elem.h:884:9,
> inlined from ‘rte_ring_enqueue_burst_elem’ at
> ../lib/librte_ring/rte_ring_elem.h:946:10,
> inlined from ‘rte_ring_enqueue_burst’ at
> ../lib/librte_ring/rte_ring.h:721:9,
> inlined from ‘pdump_copy’ at
> ../lib/librte_pdump/rte_pdump.c:94:13:
> ../lib/librte_ring/rte_ring_elem.h:162:40: warning: ‘*dup_bufs.36_42
> + _89’ may be used uninitialized [-Wmaybe-uninitialized]
> 162 | ring[idx] = obj[i];
> | ~~~^~~
> ../lib/librte_ring/rte_ring_elem.h:163:44: warning: ‘*dup_bufs.36_42
> + _98’ may be used uninitialized [-Wmaybe-uninitialized]
> 163 | ring[idx + 1] = obj[i + 1];
> | ~~~^~~
> ../lib/librte_ring/rte_ring_elem.h:164:44: warning: ‘*dup_bufs.36_42
> + _107’ may be used uninitialized [-Wmaybe-uninitialized]
> 164 | ring[idx + 2] = obj[i + 2];
> | ~~~^~~
> ../lib/librte_ring/rte_ring_elem.h:165:44: warning: ‘*dup_bufs.36_42
> + _116’ may be used uninitialized [-Wmaybe-uninitialized]
> 165 | ring[idx + 3] = obj[i + 3];
> | ~~~^~~
> ../lib/librte_ring/rte_ring_elem.h:169:42: warning: ‘*dup_bufs.36_42
> + _129’ may be used uninitialized [-Wmaybe-uninitialized]
> 169 | ring[idx++] = obj[i++]; /* fallthrough */
> | ~~~^
> ../lib/librte_ring/rte_ring_elem.h:171:42: warning: ‘*dup_bufs.36_42
> + _139’ may be used uninitialized [-Wmaybe-uninitialized]
> 171 | ring[idx++] = obj[i++]; /* fallthrough */
> | ~~~^
> ../lib/librte_ring/rte_ring_elem.h:173:42: warning: ‘*dup_bufs.36_42
> + _149’ may be used uninitialized [-Wmaybe-uninitialized]
> 173 | ring[idx++] = obj[i++];
>
> Actually, this is an alias warning as -O3 enables strict alias.
> This patch fixes it by replacing 'dup_bufs' with '&dup_bufs[0]'
> as the compiler represents them differently.
>
> Fixes: 278f945402c5 ("pdump: add new library for packet capture")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Joyce Kong
> Reviewed-by: Ruifeng Wang
> ---
Acked-by: Tyler Retzlaff
> lib/pdump/rte_pdump.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/pdump/rte_pdump.c b/lib/pdump/rte_pdump.c
> index 9bc4bab4f2..53cca1034d 100644
> --- a/lib/pdump/rte_pdump.c
> +++ b/lib/pdump/rte_pdump.c
> @@ -134,7 +134,7 @@ pdump_copy(uint16_t port_id, uint16_t queue,
>
> __atomic_fetch_add(&stats->accepted, d_pkts, __ATOMIC_RELAXED);
>
> - ring_enq = rte_ring_enqueue_burst(ring, (void *)dup_bufs, d_pkts, NULL);
> + ring_enq = rte_ring_enqueue_burst(ring, (void *)&dup_bufs[0], d_pkts,
> NULL);
nit: i would drop the cast to void *, it shouldn't be needed?
[PATCH] devtools: move mailmap check after patch applied
The names in a patch were possibly checked with checkpatches.sh
before applying the patch, so before .mailmap file was updated.
The check is moved and translated in check-git-log.sh,
which is run only on a repository, not a detached patch file.
Fixes: e83d41f0694d ("mailmap: add list of contributors")
Cc: sta...@dpdk.org
Signed-off-by: Thomas Monjalon
---
devtools/check-git-log.sh | 15 +++
devtools/checkpatches.sh | 30 --
2 files changed, 15 insertions(+), 30 deletions(-)
diff --git a/devtools/check-git-log.sh b/devtools/check-git-log.sh
index e26205814b..af751e49ab 100755
--- a/devtools/check-git-log.sh
+++ b/devtools/check-git-log.sh
@@ -259,6 +259,21 @@ done)
[ -z "$bad" ] || { printf "Missing 'Signed-off-by:' tag: \n$bad\n"\
&& failure=true;}
+# check names
+names=$(git log --format='From: %an <%ae>%n%b' --reverse $range |
+ sed -rn 's,.*: (.*<.*@.*>),\1,p' |
+ sort -u)
+bad=$(for contributor in $names ; do
+ ! grep -qE "^$contributor($| <)" $selfdir/../.mailmap || continue
+ if grep -q "^${contributor%% <*} <" .mailmap ; then
+ printf "\t$contributor is not the primary email address\n"
+ else
+ printf "\t$contributor is unknown in .mailmap\n"
+ fi
+done)
+[ -z "$bad" ] || { printf "Contributor name/email mismatch with .mailmap:
\n$bad\n"\
+ && failure=true;}
+
total=$(echo "$commits" | wc -l)
if $failure ; then
printf "\nInvalid patch(es) found - checked $total patch"
diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
index 1dee094c7a..a07bbc83cb 100755
--- a/devtools/checkpatches.sh
+++ b/devtools/checkpatches.sh
@@ -248,28 +248,6 @@ check_release_notes() { #
grep -v $current_rel_notes
}
-check_names() { #
- res=0
-
- old_IFS=$IFS
- IFS='
-'
- for contributor in $(sed -rn '/^$/,/^--- / {s/.*: (.*<.*@.*>)/\1/p}'
$1); do
- ! grep -qE "^$contributor($| <)" .mailmap || continue
- name=${contributor%% <*}
- if grep -q "^$name <" .mailmap; then
- reason="$name mail differs from primary mail"
- else
- reason="$contributor is unknown"
- fi
- echo "$reason, please fix the commit message or update
.mailmap."
- res=1
- done
- IFS=$old_IFS
-
- return $res
-}
-
number=0
range='origin/main..'
quiet=false
@@ -378,14 +356,6 @@ check () { #
ret=1
fi
- ! $verbose || printf '\nChecking names in commit log:\n'
- report=$(check_names "$tmpinput")
- if [ $? -ne 0 ] ; then
- $headline_printed || print_headline "$subject"
- printf '%s\n' "$report"
- ret=1
- fi
-
if [ "$tmpinput" != "$1" ]; then
rm -f "$tmpinput"
trap - INT
--
2.39.1
RE: [PATCH v3] net/mlx5: fix the sysfs port name translation
From: Bing Zhao
> With some OFED or upstream kernel of mlx5, the port name fetched from
> "/sys/class/net/[DEV]/phys_port_name" may have a tailing "\n" as the EOL.
> The sscanf() will return the scanned items number with this EOL.
>
> In such case, the "equal to" condition is considered as false and the function
> mlx5_translate_port_name() will recognize the port type wrongly with
> UNKNOWN result.
>
> The tailing carriage return character should be removed before calling the
> mlx5_translate_port_name(), this was already done in the NL message
> handling. In the meanwhile, the possible incorrect line feed character is also
> taken into consideration.
>
> Fixes: 654810b56828 ("common/mlx5: share Netlink commands")
> Fixes: 420bbdae89f2 ("net/mlx5: fix host physical function representor
> naming")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Bing Zhao
Acked-by: Matan Azrad
RE: [PATCH] net/mlx5: fix CQEs dumping for Tx
From: Alexander Kozyrev
> The regular CQE size can be 64 bytes or 128 bytes depending on the cache
> line size. The error CQE is always 64 bytes long.
> Only 64 bytes are dumped to the log file in case of Tx queue recovery form
> the error. Use the CQE size, not the error CQE size.
>
> Fixes: 957e45fb7b ("net/mlx5: handle Tx completion with error")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Alexander Kozyrev
Acked-by: Matan Azrad
RE: [EXT] [PATCH] vhost: add device op to offload the interrupt kick
Hi Eelco,
> +void
> +rte_vhost_notify_guest(int vid, uint16_t queue_id) {
> + struct virtio_net *dev = get_device(vid);
> + struct vhost_virtqueue *vq;
> +
> + if (!dev || queue_id >= VHOST_MAX_VRING)
> + return;
> +
> + vq = dev->virtqueue[queue_id];
> + if (!vq)
> + return;
> +
> + rte_spinlock_lock(&vq->access_lock);
> +
Is spin lock needed here before system call ?
> + if (vq->callfd >= 0)
> + eventfd_write(vq->callfd, (eventfd_t)1);
> +
> + rte_spinlock_unlock(&vq->access_lock);
> +}
> +
Thanks.
RE: [PATCH 0/3] use C11 memory model GCC builtin atomics
> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] > Sent: Monday, 27 March 2023 16.30 > > Replace the use of __sync__and_fetch and __sync_fetch_and_ atomics > with GCC C11 memory model __atomic builtins. > > This series contributes to converging on standard atomics in 23.11 but is > kept separate as there may be sensitivity to converting from __sync to the > C11 memory model builtins. > > Tyler Retzlaff (3): > bus/vmbus: use C11 memory model GCC builtin atomics > crypto/ccp: use C11 memory model GCC builtin atomics > eal: use C11 memory model GCC builtin atomics > > drivers/bus/vmbus/vmbus_channel.c| 2 +- > drivers/crypto/ccp/ccp_dev.c | 6 -- > lib/eal/include/generic/rte_atomic.h | 32 > 3 files changed, 21 insertions(+), 19 deletions(-) > > -- > 1.8.3.1 > Series-reviewed-by: Morten Brørup
Re: [EXT] [PATCH] vhost: add device op to offload the interrupt kick
On 27 Mar 2023, at 17:16, Gowrishankar Muthukrishnan wrote:
> Hi Eelco,
>
>> +void
>> +rte_vhost_notify_guest(int vid, uint16_t queue_id) {
>> +struct virtio_net *dev = get_device(vid);
>> +struct vhost_virtqueue *vq;
>> +
>> +if (!dev || queue_id >= VHOST_MAX_VRING)
>> +return;
>> +
>> +vq = dev->virtqueue[queue_id];
>> +if (!vq)
>> +return;
>> +
>> +rte_spinlock_lock(&vq->access_lock);
>> +
>
> Is spin lock needed here before system call ?
I assumed access_lock is protecting all the following fields in this structure,
so I need the lock to read the vq->callfd, however, I can/should move the
eventfd_write outside of the lock.
>> +if (vq->callfd >= 0)
>> +eventfd_write(vq->callfd, (eventfd_t)1);
>> +
>> +rte_spinlock_unlock(&vq->access_lock);
>> +}
>> +
>
> Thanks.
Re: [EXT] [PATCH] vhost: add device op to offload the interrupt kick
On 3/27/23 18:04, Eelco Chaudron wrote:
On 27 Mar 2023, at 17:16, Gowrishankar Muthukrishnan wrote:
Hi Eelco,
+void
+rte_vhost_notify_guest(int vid, uint16_t queue_id) {
+ struct virtio_net *dev = get_device(vid);
+ struct vhost_virtqueue *vq;
+
+ if (!dev || queue_id >= VHOST_MAX_VRING)
+ return;
+
+ vq = dev->virtqueue[queue_id];
+ if (!vq)
+ return;
+
+ rte_spinlock_lock(&vq->access_lock);
+
Is spin lock needed here before system call ?
I assumed access_lock is protecting all the following fields in this structure, so
I need the lock to read the vq->callfd, however, I can/should move the
eventfd_write outside of the lock.
The FD might be closed between the check and the call to eventfd_write
though, but I agree this is not optimal to call the eventfd_write under
the spinlock in your case, as you will block the pmd thread if it tries
to enqueue/dequeue packets on this queue, defeating the purpose of this
patch.
Maybe the solution is to change to read-write locks for the access_lock
spinlock. The datapath (rte_vhost_enqueue_burst/rte_vhost_dequeue_burst)
and this API would use the read version, meaning they won't lock each
other, and the control path (lib/vhost/vhost_user.c) will use the write
version.
Does that make sense?
Maxime
+ if (vq->callfd >= 0)
+ eventfd_write(vq->callfd, (eventfd_t)1);
+
+ rte_spinlock_unlock(&vq->access_lock);
+}
+
Thanks.
rte_atomic API compatibility & standard atomics
Hi folks, I don't think we discussed it specifically but what is the expectation in relation to converting to standard atomics and compatibility of the legacy rte_atomic APIs? We can't really convert the inline function implementations of the rte_atomic APIs because doing so would break compatibility. This is because if the implementation uses standard atomics APIs then we are required to pass _Atomic types to the generic atomic intrinsics. We can choose to just leave the rte_atomic API implementations as they are using the GCC builtins and i'm fine with that, but I do need some help with what to do with msvc then since it doesn't have those builtins. The options seem to be as follows. 1. Just cast the non-atomic types in the rte_atomic APIs implementation to _Atomic which may work but i'm pretty sure is undefined behavior since you can't qualify a non _Atomic type to suddenly be _Atomic. 2. We could conditionally compile (hide) the legacy rte_atomic APIs when msvc is in use, this seems not bad since there technically aren't any Windows/MSVC consumers, but if someone wanted to port an existing application they would have to adapt the code to avoid use of rte_atomic. For now I think the safest option is to go with 2 since it doesn't impose any compatibility risk and conditional compilation only exists until we deprecate and remove the old rte_atomic APIs. Are there any other options i'm missing here? Thanks
RE: rte_atomic API compatibility & standard atomics
> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> Sent: Monday, 27 March 2023 21.39
>
> Hi folks,
>
> I don't think we discussed it specifically but what is the expectation
> in relation to converting to standard atomics and compatibility of the
> legacy rte_atomic APIs?
>
> We can't really convert the inline function implementations of the
> rte_atomic APIs because doing so would break compatibility. This is
> because if the implementation uses standard atomics APIs then we are
> required to pass _Atomic types to the generic atomic intrinsics.
>
> We can choose to just leave the rte_atomic API implementations as they
> are using the GCC builtins and i'm fine with that, but I do need some
> help with what to do with msvc then since it doesn't have those
> builtins.
>
> The options seem to be as follows.
>
> 1.
> Just cast the non-atomic types in the rte_atomic APIs implementation
> to _Atomic which may work but i'm pretty sure is undefined behavior
> since
> you can't qualify a non _Atomic type to suddenly be _Atomic.
>
> 2.
> We could conditionally compile (hide) the legacy rte_atomic APIs when
> msvc is in use, this seems not bad since there technically aren't any
> Windows/MSVC consumers, but if someone wanted to port an existing
> application they would have to adapt the code to avoid use of
> rte_atomic.
>
> For now I think the safest option is to go with 2 since it doesn't
> impose any compatibility risk and conditional compilation only exists
> until we deprecate and remove the old rte_atomic APIs.
>
> Are there any other options i'm missing here?
>
> Thanks
As a variant of your second option, you could make most of the legacy
rte_atomic APIs available to MSVC by changing the atomic counter types from
volatile to _Atomic. Then only the atomic cmpset() and exchange() functions are
unavailable for the application. E.g. for the 32 bit atomic counter type:
typedef struct {
- volatile int32_t cnt; /**< An internal counter value. */
+ _Atomic int32_t cnt; /**< An internal counter value. */
} rte_atomic32_t;
[Bug 1200] mlx5_tx_handle_completion: bad timestamp
https://bugs.dpdk.org/show_bug.cgi?id=1200 smiller (7532ya...@gmail.com) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from smiller (7532ya...@gmail.com) --- I am withdrawing this BF. This feature is simply unsupported in DPDK. -- You are receiving this mail because: You are the assignee for the bug.
[PATCH 0/2] update license and copyright
This patch set contains: 1. switch copyright from MIT to BSD-3 for GVE base code. 2. remove MIT license exception 3. add maintainers 4. update copyright holders for GVE Junfeng Guo (2): net/gve: switch copyright from MIT to BSD-3 net/gve: update copyright holders .mailmap| 1 + MAINTAINERS | 3 +++ drivers/net/gve/base/gve.h | 32 ++--- drivers/net/gve/base/gve_adminq.c | 32 ++--- drivers/net/gve/base/gve_adminq.h | 32 ++--- drivers/net/gve/base/gve_desc.h | 32 ++--- drivers/net/gve/base/gve_desc_dqo.h | 32 ++--- drivers/net/gve/base/gve_osdep.h| 31 ++-- drivers/net/gve/base/gve_register.h | 32 ++--- drivers/net/gve/gve_ethdev.c| 32 +++-- drivers/net/gve/gve_ethdev.h| 32 +++-- drivers/net/gve/gve_logs.h | 32 +++-- drivers/net/gve/gve_rx.c| 32 +++-- drivers/net/gve/gve_tx.c| 32 +++-- drivers/net/gve/meson.build | 31 +++- license/exceptions.txt | 1 - 16 files changed, 387 insertions(+), 32 deletions(-) -- 2.34.1
[PATCH 1/2] net/gve: switch copyright from MIT to BSD-3
Switch copyright from MIT to BSD-3 for GVE base code. In the meantime, remove MIT license exception for GVE driver. Also update the maintainers for GVE driver. Signed-off-by: Rushil Gupta Signed-off-by: Joshua Washington Signed-off-by: Junfeng Guo Signed-off-by: Jeroen de Borst --- .mailmap| 1 + MAINTAINERS | 3 +++ drivers/net/gve/base/gve.h | 32 ++--- drivers/net/gve/base/gve_adminq.c | 32 ++--- drivers/net/gve/base/gve_adminq.h | 32 ++--- drivers/net/gve/base/gve_desc.h | 32 ++--- drivers/net/gve/base/gve_desc_dqo.h | 32 ++--- drivers/net/gve/base/gve_osdep.h| 31 ++-- drivers/net/gve/base/gve_register.h | 32 ++--- license/exceptions.txt | 1 - 10 files changed, 207 insertions(+), 21 deletions(-) diff --git a/.mailmap b/.mailmap index dc30369117..9d66fa727c 100644 --- a/.mailmap +++ b/.mailmap @@ -588,6 +588,7 @@ Jens Freimann Jeremy Plsek Jeremy Spewock Jerin Jacob +Jeroen de Borst Jerome Jutteau Jerry Hao OS Jerry Lilijun diff --git a/MAINTAINERS b/MAINTAINERS index 1a33ad8592..988c7aecfa 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -714,6 +714,9 @@ F: doc/guides/nics/features/enic.ini Google Virtual Ethernet M: Junfeng Guo +M: Jeroen de Borst +M: Rushil Gupta +M: Joshua Washington F: drivers/net/gve/ F: doc/guides/nics/gve.rst F: doc/guides/nics/features/gve.ini diff --git a/drivers/net/gve/base/gve.h b/drivers/net/gve/base/gve.h index 2dc4507acb..ac0fc1472e 100644 --- a/drivers/net/gve/base/gve.h +++ b/drivers/net/gve/base/gve.h @@ -1,6 +1,32 @@ -/* SPDX-License-Identifier: MIT - * Google Virtual Ethernet (gve) driver - * Copyright (C) 2015-2022 Google, Inc. +/* + * SPDX-License-Identifier: BSD-3-Clause + * + * Copyright (c) 2022-2023 Google LLC + * + * Redistribution and use in source and binary forms, with or without modification, + * are permitted provided that the following conditions are met: + * + * 1. Redistributions of source code must retain the above copyright notice, this + *list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright notice, + *this list of conditions and the following disclaimer in the documentation + *and/or other materials provided with the distribution. + * + * 3. Neither the name of the copyright holder nor the names of its contributors + *may be used to endorse or promote products derived from this software without + *specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR + * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ #ifndef _GVE_H_ diff --git a/drivers/net/gve/base/gve_adminq.c b/drivers/net/gve/base/gve_adminq.c index e745b709b2..778d3f9416 100644 --- a/drivers/net/gve/base/gve_adminq.c +++ b/drivers/net/gve/base/gve_adminq.c @@ -1,6 +1,32 @@ -/* SPDX-License-Identifier: MIT - * Google Virtual Ethernet (gve) driver - * Copyright (C) 2015-2022 Google, Inc. +/* + * SPDX-License-Identifier: BSD-3-Clause + * + * Copyright (c) 2022-2023 Google LLC + * + * Redistribution and use in source and binary forms, with or without modification, + * are permitted provided that the following conditions are met: + * + * 1. Redistributions of source code must retain the above copyright notice, this + *list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright notice, + *this list of conditions and the following disclaimer in the documentation + *and/or other materials provided with the distribution. + * + * 3. Neither the name of the copyright holder nor the names of its contributors + *may be used to endorse or promote products derived from this software without + *specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL
[PATCH 2/2] net/gve: update copyright holders
Add Google LLC as one of the copyright holders for GVE. Signed-off-by: Rushil Gupta Signed-off-by: Joshua Washington Signed-off-by: Junfeng Guo Signed-off-by: Jeroen de Borst --- drivers/net/gve/gve_ethdev.c | 32 ++-- drivers/net/gve/gve_ethdev.h | 32 ++-- drivers/net/gve/gve_logs.h | 32 ++-- drivers/net/gve/gve_rx.c | 32 ++-- drivers/net/gve/gve_tx.c | 32 ++-- drivers/net/gve/meson.build | 31 ++- 6 files changed, 180 insertions(+), 11 deletions(-) diff --git a/drivers/net/gve/gve_ethdev.c b/drivers/net/gve/gve_ethdev.c index cf28a4a3b7..1b8f0fde8f 100644 --- a/drivers/net/gve/gve_ethdev.c +++ b/drivers/net/gve/gve_ethdev.c @@ -1,5 +1,33 @@ -/* SPDX-License-Identifier: BSD-3-Clause - * Copyright(C) 2022 Intel Corporation +/* + * SPDX-License-Identifier: BSD-3-Clause + * + * Copyright (c) 2022-2023 Google LLC + * Copyright (c) 2022-2023 Intel Corporation + * + * Redistribution and use in source and binary forms, with or without modification, + * are permitted provided that the following conditions are met: + * + * 1. Redistributions of source code must retain the above copyright notice, this + *list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright notice, + *this list of conditions and the following disclaimer in the documentation + *and/or other materials provided with the distribution. + * + * 3. Neither the name of the copyright holder nor the names of its contributors + *may be used to endorse or promote products derived from this software without + *specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR + * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ #include "gve_ethdev.h" diff --git a/drivers/net/gve/gve_ethdev.h b/drivers/net/gve/gve_ethdev.h index 42a02cf5d4..f600c02932 100644 --- a/drivers/net/gve/gve_ethdev.h +++ b/drivers/net/gve/gve_ethdev.h @@ -1,5 +1,33 @@ -/* SPDX-License-Identifier: BSD-3-Clause - * Copyright(C) 2022 Intel Corporation +/* + * SPDX-License-Identifier: BSD-3-Clause + * + * Copyright (c) 2022-2023 Google LLC + * Copyright (c) 2022-2023 Intel Corporation + * + * Redistribution and use in source and binary forms, with or without modification, + * are permitted provided that the following conditions are met: + * + * 1. Redistributions of source code must retain the above copyright notice, this + *list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright notice, + *this list of conditions and the following disclaimer in the documentation + *and/or other materials provided with the distribution. + * + * 3. Neither the name of the copyright holder nor the names of its contributors + *may be used to endorse or promote products derived from this software without + *specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR + * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ #ifndef _GVE_ETHDEV_H_ diff --git a/drivers/net/gve/gve_logs.h b/drivers/net/gve/gve_logs.h index 0d02da46e1..a784ac5799 100644 --- a/drivers/net/gve/gve_logs.h +++ b/drivers/net/gve/gve_logs.h @@ -1,5 +1,33 @@ -/* SPDX-License-Identifier: BSD-3-Clause - * Copyright(C) 2022 Intel Corporation +/* + * SPDX-License-Identifier: BSD-3-Clause + * + * Copyright (c) 2022-2023 Google LLC + * Copy
RE: [PATCH 1/2] net/virtio: propagate return value of called function
> -Original Message-
> From: Boleslav Stankevich
> Sent: Wednesday, March 22, 2023 6:23 PM
> To: dev@dpdk.org
> Cc: Boleslav Stankevich ;
> sta...@dpdk.org; Andrew Rybchenko ; Maxime
> Coquelin ; Xia, Chenbo ;
> David Marchand ; Hyong Youb Kim
> ; Harman Kalra
> Subject: [PATCH 1/2] net/virtio: propagate return value of called function
>
> rte_intr_vec_list_alloc() may fail because of different reasons which
> are indicated by different negative errno values.
>
> Fixes: d61138d4f0e2 ("drivers: remove direct access to interrupt handle")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Boleslav Stankevich
> Signed-off-by: Andrew Rybchenko
I see Boleslav's email is updated in mailmap file but patchwork is still
complaining
about it.
@Adrew & Maxime,
Do you know why?
Thanks,
Chenbo
> ---
> drivers/net/virtio/virtio_ethdev.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_ethdev.c
> b/drivers/net/virtio/virtio_ethdev.c
> index ae84d313be..5c8b7b95e9 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -1390,6 +1390,7 @@ static int
> virtio_configure_intr(struct rte_eth_dev *dev)
> {
> struct virtio_hw *hw = dev->data->dev_private;
> + int ret;
>
> if (!rte_intr_cap_multiple(dev->intr_handle)) {
> PMD_INIT_LOG(ERR, "Multiple intr vector not supported");
> @@ -1401,11 +1402,12 @@ virtio_configure_intr(struct rte_eth_dev *dev)
> return -1;
> }
>
> - if (rte_intr_vec_list_alloc(dev->intr_handle, "intr_vec",
> - hw->max_queue_pairs)) {
> + ret = rte_intr_vec_list_alloc(dev->intr_handle, "intr_vec",
> + hw->max_queue_pairs);
> + if (ret < 0) {
> PMD_INIT_LOG(ERR, "Failed to allocate %u rxq vectors",
>hw->max_queue_pairs);
> - return -ENOMEM;
> + return ret;
> }
>
> if (dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC) {
> --
> 2.30.2
RE: [PATCH] pdump: fix build issue with GCC 12
> -Original Message-
> From: Tyler Retzlaff
> Sent: Monday, March 27, 2023 10:35 PM
> To: Joyce Kong
> Cc: reshma.pat...@intel.com; step...@networkplumber.org;
> konstantin.v.anan...@yandex.ru; dev@dpdk.org; nd ;
> sta...@dpdk.org; Ruifeng Wang
> Subject: Re: [PATCH] pdump: fix build issue with GCC 12
>
> On Mon, Mar 27, 2023 at 07:07:12AM +, Joyce Kong wrote:
> > The following warning is observed with GCC12 compilation with release
> > 20.11:
> >
> > In function ‘__rte_ring_enqueue_elems_64’,
> > inlined from ‘__rte_ring_enqueue_elems’ at
> > ../lib/librte_ring/rte_ring_elem.h:225:3,
> > inlined from ‘__rte_ring_do_enqueue_elem’ at
> > ../lib/librte_ring/rte_ring_elem.h:424:2,
> > inlined from ‘rte_ring_mp_enqueue_burst_elem’ at
> > ../lib/librte_ring/rte_ring_elem.h:884:9,
> > inlined from ‘rte_ring_enqueue_burst_elem’ at
> > ../lib/librte_ring/rte_ring_elem.h:946:10,
> > inlined from ‘rte_ring_enqueue_burst’ at
> > ../lib/librte_ring/rte_ring.h:721:9,
> > inlined from ‘pdump_copy’ at
> > ../lib/librte_pdump/rte_pdump.c:94:13:
> > ../lib/librte_ring/rte_ring_elem.h:162:40: warning: ‘*dup_bufs.36_42
> > + _89’ may be used uninitialized [-Wmaybe-uninitialized]
> > 162 | ring[idx] = obj[i];
> > | ~~~^~~
> > ../lib/librte_ring/rte_ring_elem.h:163:44: warning: ‘*dup_bufs.36_42
> > + _98’ may be used uninitialized [-Wmaybe-uninitialized]
> > 163 | ring[idx + 1] = obj[i + 1];
> > | ~~~^~~
> > ../lib/librte_ring/rte_ring_elem.h:164:44: warning: ‘*dup_bufs.36_42
> > + _107’ may be used uninitialized [-Wmaybe-uninitialized]
> > 164 | ring[idx + 2] = obj[i + 2];
> > | ~~~^~~
> > ../lib/librte_ring/rte_ring_elem.h:165:44: warning: ‘*dup_bufs.36_42
> > + _116’ may be used uninitialized [-Wmaybe-uninitialized]
> > 165 | ring[idx + 3] = obj[i + 3];
> > | ~~~^~~
> > ../lib/librte_ring/rte_ring_elem.h:169:42: warning: ‘*dup_bufs.36_42
> > + _129’ may be used uninitialized [-Wmaybe-uninitialized]
> > 169 | ring[idx++] = obj[i++]; /* fallthrough */
> > | ~~~^
> > ../lib/librte_ring/rte_ring_elem.h:171:42: warning: ‘*dup_bufs.36_42
> > + _139’ may be used uninitialized [-Wmaybe-uninitialized]
> > 171 | ring[idx++] = obj[i++]; /* fallthrough */
> > | ~~~^
> > ../lib/librte_ring/rte_ring_elem.h:173:42: warning: ‘*dup_bufs.36_42
> > + _149’ may be used uninitialized [-Wmaybe-uninitialized]
> > 173 | ring[idx++] = obj[i++];
> >
> > Actually, this is an alias warning as -O3 enables strict alias.
> > This patch fixes it by replacing 'dup_bufs' with '&dup_bufs[0]'
> > as the compiler represents them differently.
> >
> > Fixes: 278f945402c5 ("pdump: add new library for packet capture")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Joyce Kong
> > Reviewed-by: Ruifeng Wang
> > ---
>
> Acked-by: Tyler Retzlaff
>
> > lib/pdump/rte_pdump.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/pdump/rte_pdump.c b/lib/pdump/rte_pdump.c index
> > 9bc4bab4f2..53cca1034d 100644
> > --- a/lib/pdump/rte_pdump.c
> > +++ b/lib/pdump/rte_pdump.c
> > @@ -134,7 +134,7 @@ pdump_copy(uint16_t port_id, uint16_t queue,
> >
> > __atomic_fetch_add(&stats->accepted, d_pkts, __ATOMIC_RELAXED);
> >
> > - ring_enq = rte_ring_enqueue_burst(ring, (void *)dup_bufs, d_pkts,
> NULL);
> > + ring_enq = rte_ring_enqueue_burst(ring, (void *)&dup_bufs[0],
> > +d_pkts, NULL);
>
> nit: i would drop the cast to void *, it shouldn't be needed?
Removing 'void *' here would generate a warning from incompatible pointer type,
as rte_ring_enqueue_burst(struct rte_ring *r, void * const *obj_table, ...)
expected
'void * const *', but argument of &dup_bufs[0] is of type 'struct rte_mbuf **'.
RE: [PATCH] test/crypto: fix errors for test stats testcase
> Hi Saoirse,
>
> > Subject: [PATCH] test/crypto: fix errors for test stats testcase
> >
> > The test stats testcase was printing the same error message for multiple
> > errors
> > in the test stats testcase. This is now replaced with descriptive error
> > messages,
> > which match the cause of the failure.
> >
> > Fixes: 202d375 ("app/test: add cryptodev unit and performance tests")
> > Cc: sta...@dpdk.org
> > Cc: declan.dohe...@intel.com
> >
> > Signed-off-by: Saoirse O'Donovan
> > ---
> > .mailmap | 1 +
> > app/test/test_cryptodev.c | 12 ++--
> > 2 files changed, 7 insertions(+), 6 deletions(-)
>
> Acked-by: Ciara Power
Applied to dpdk-next-crypto
Changed title to "test/crypto: fix stats case error messages"
RE: [PATCH] doc: fix cryptodev code block mismatch
> Acked-by: Hemant Agrawal Applied to dpdk-next-crypto Thanks.
RE: [PATCH] examples/fips_validation: fix digest in non JSON SHA MCT
> Hi Gowrishankar,
> > Subject: [PATCH] examples/fips_validation: fix digest in non JSON SHA MCT
> >
> > Non JSON SHA MCT tests produce incorrect digest due to a regression while
> > handling MD blocks in common for all kind of SHA, SHA2, SHA3 and SHAKE
> > algorithms. Fixing this along with some cleanup to use only rte_malloc API
> > for
> > storing test vectors as in other tests.
> >
> > Fixes: d8417b5ef4e ("examples/fips_validation: add SHA3 validation")
> >
> > Signed-off-by: Gowrishankar Muthukrishnan
> Tested-by: Brian Dooley
Applied to dpdk-next-crypto
Fixes tag changed to
1ea7940e0f44 ("examples/fips_validation: add SHA3 validation")
Thanks.
