DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@amd.com>
To: "Mattias Rönnblom" <hofors@lysator.liu.se>,
	"John W. Linville" <linville@tuxdriver.com>
Cc: "Thomas Monjalon" <thomas@monjalon.net>,
	dev@dpdk.org, "Mattias Rönnblom" <mattias.ronnblom@ericsson.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	"Morten Brørup" <mb@smartsharesystems.com>
Subject: Re: [RFC v2] net/af_packet: make stats reset reliable
Date: Thu, 2 May 2024 15:22:35 +0100	[thread overview]
Message-ID: <422dd5a6-4ed6-4ae5-b613-b22a7cf6f77d@amd.com> (raw)
In-Reply-To: <dc72ace9-9c13-478c-a3a1-08c9552de848@lysator.liu.se>

On 5/2/2024 6:51 AM, Mattias Rönnblom wrote:
> On 2024-05-01 18:19, Ferruh Yigit wrote:
>> On 4/28/2024 4:11 PM, Mattias Rönnblom wrote:
>>> On 2024-04-26 16:38, Ferruh Yigit wrote:
>>>> For stats reset, use an offset instead of zeroing out actual stats
>>>> values,
>>>> get_stats() displays diff between stats and offset.
>>>> This way stats only updated in datapath and offset only updated in
>>>> stats
>>>> reset function. This makes stats reset function more reliable.
>>>>
>>>> As stats only written by single thread, we can remove 'volatile'
>>>> qualifier
>>>> which should improve the performance in datapath.
>>>>
>>>
>>> volatile wouldn't help you if you had multiple writers, so that can't be
>>> the reason for its removal. It would be more accurate to say it should
>>> be replaced with atomic updates. If you don't use volatile and don't use
>>> atomics, you have to consider if the compiler can reach the conclusion
>>> that it does not need to store the counter value for future use *for
>>> that thread*. Since otherwise, I don't think the store actually needs to
>>> occur. Since DPDK statistics tend to work, it's pretty obvious that
>>> current compilers tend not to reach this conclusion.
>>>
>>
>> Thanks Mattias for clarifying why we need volatile or atomics even with
>> single writer.
>>
>>> If this should be done 100% properly, the update operation should be a
>>> non-atomic load, non-atomic add, and an atomic store. Similarly, for the
>>> reset, the offset store should be atomic.
>>>
>>
>> ack
>>
>>> Considered the state of the rest of the DPDK code base, I think a
>>> non-atomic, non-volatile solution is also fine.
>>>
>>
>> Yes, this seems working practically but I guess better to follow above
>> suggestion.
>>
>>> (That said, I think we're better off just deprecating stats reset
>>> altogether, and returning -ENOTSUP here meanwhile.)
>>>
>>
>> As long as reset is reliable (here I mean it reset stats in every call)
>> and doesn't impact datapath performance, I am for to continue with it.
>> Returning non supported won't bring more benefit to users.
>>
>>>> Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
>>>> ---
>>>> Cc: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
>>>> Cc: Stephen Hemminger <stephen@networkplumber.org>
>>>> Cc: Morten Brørup <mb@smartsharesystems.com>
>>>>
>>>> This update triggered by mail list discussion [1].
>>>>
>>>> [1]
>>>> https://inbox.dpdk.org/dev/3b2cf48e-2293-4226-b6cd-5f4dd3969f99@lysator.liu.se/
>>>>
>>>> v2:
>>>> * Remove wrapping check for stats
>>>> ---
>>>>    drivers/net/af_packet/rte_eth_af_packet.c | 66
>>>> ++++++++++++++---------
>>>>    1 file changed, 41 insertions(+), 25 deletions(-)
>>>>
>>>> diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
>>>> b/drivers/net/af_packet/rte_eth_af_packet.c
>>>> index 397a32db5886..10c8e1e50139 100644
>>>> --- a/drivers/net/af_packet/rte_eth_af_packet.c
>>>> +++ b/drivers/net/af_packet/rte_eth_af_packet.c
>>>> @@ -51,8 +51,10 @@ struct pkt_rx_queue {
>>>>        uint16_t in_port;
>>>>        uint8_t vlan_strip;
>>>>    -    volatile unsigned long rx_pkts;
>>>> -    volatile unsigned long rx_bytes;
>>>> +    uint64_t rx_pkts;
>>>> +    uint64_t rx_bytes;
>>>> +    uint64_t rx_pkts_offset;
>>>> +    uint64_t rx_bytes_offset;
>>>
>>> I suggest you introduce a separate struct for reset-able counters. It'll
>>> make things cleaner, and you can sneak in atomics without too much
>>> atomics-related bloat.
>>>
>>> struct counter
>>> {
>>>      uint64_t count;
>>>      uint64_t offset;
>>> };
>>>
>>> /../
>>>      struct counter rx_pkts;
>>>      struct counter rx_bytes;
>>> /../
>>>
>>> static uint64_t
>>> counter_value(struct counter *counter)
>>> {
>>>      uint64_t count = __atomic_load_n(&counter->count,
>>> __ATOMIC_RELAXED);
>>>      uint64_t offset = __atomic_load_n(&counter->offset,
>>> __ATOMIC_RELAXED);
>>>
>>>      return count + offset;
>>> }
>>>
>>> static void
>>> counter_reset(struct counter *counter)
>>> {
>>>      uint64_t count = __atomic_load_n(&counter->count,
>>> __ATOMIC_RELAXED);
>>>
>>>      __atomic_store_n(&counter->offset, count, __ATOMIC_RELAXED);
>>> }
>>>
>>> static void
>>> counter_add(struct counter *counter, uint64_t operand)
>>> {
>>>      __atomic_store_n(&counter->count, counter->count + operand,
>>> __ATOMIC_RELAXED);
>>> }
>>>
>>
>> Ack for separate struct for reset-able counters.
>>
>>> You'd have to port this to <rte_stdatomic.h> calls, which prevents
>>> non-atomic loads from RTE_ATOMIC()s. The non-atomic reads above must be
>>> replaced with explicit relaxed non-atomic load. Otherwise, if you just
>>> use "counter->count", that would be an atomic load with sequential
>>> consistency memory order on C11 atomics-based builds, which would result
>>> in a barrier, at least on weakly ordered machines (e.g., ARM).
>>>
>>
>> I am not sure I understand above.
>> As load and add will be non-atomic, why not access them directly, like:
>> `uint64_t count = counter->count;`
>>
> 
> In case count is _Atomic (i.e., on enable_stdatomic=true builds), "count
> = counter->count" will imply a memory barrier. On x86_64, I think it
> will "only" be a compiler barrier (i.e., preventing optimization). On
> weakly ordered machines, it will result in a barrier-instruction (or an
> instruction-which-is-also-a-barrier, like in the example below).
> 
> include <stdatomic.h>
> 
> int relaxed_load(_Atomic int *p)
> {
>     atomic_load_explicit(p, memory_order_relaxed);
> }
> 
> int direct_load(_Atomic int *p)
> {
>     return *p;
> }
> 
> GCC 13.2 ARM64 ->
> 
> relaxed_load:
>         ldr     w0, [x0]
>         ret
> direct_load:
>         ldar    w0, [x0]
>         ret
> 
>


Do we need to declare count as '_Atomic', I wasn't planning to make
variable _Atomic. This way assignment won't introduce any memory barrier.


>> So my understanding is, remove `volatile`, load and add without atomics,
>> and only use relaxed ordered atomics for store (to ensure value in
>> register stored to memory).
>>
> 
> Yes, that would be the best option, would the DPDK atomics API allow its
> implementation - but it doesn't. At least not if you care about what
> happens in enable_stdatomic=true builds.
> 
> The second-best option is to use a rte_memory_order_relaxed atomic load,
> a regular non-atomic add, and a relaxed atomic store.
> 
>> I will send a new version of RFC with above understanding.
>>
>>> I would still use a struct and some helper-functions even for the less
>>> ambitious, non-atomic variant.
>>>
>>> The only drawback of using GCC built-ins type atomics here, versus an
>>> atomic- and volatile-free approach, is that current compilers seems to
>>> refuse merging atomic stores. It's beyond me why this is the case. If
>>> you store to a variable twice in quick succession, it'll be two store
>>> machine instructions, even in cases where the compiler *knows* the value
>>> is identical. So volatile, even though you didn't ask for it. Weird.
>>>
>>> So if you have a loop, you may want to make an "counter_add()" in the
>>> end from a temporary, to get the final 0.001% of performance.
>>>
>>
>> ack
>>
>> I can't really say which one of the following is better (because of
>> store in empty poll), but I will keep it as it is (b.):
>>
>> a.
>> for (i < nb_pkt) {
>>     stats =+ 1;
>> }
>>
>>
>> b.
>> for (i < nb_pkt) {
>>     tmp =+ 1;
>> }
>> stats += tmp;
>>
>>
>> c.
>> for (i < nb_pkt) {
>>     tmp =+ 1;
>> }
>> if (tmp)
>>     stats += tmp;
>>
>>
>>
>>> If the tech board thinks MT-safe reset-able software-manage statistics
>>> is the future (as opposed to dropping reset support, for example), I
>>> think this stuff should go into a separate header file, so other PMDs
>>> can reuse it. Maybe out of scope for this patch.
>>>
>>
>> I don't think we need MT-safe reset, the patch is already out to
>> document current status.
> 
> Well, what you are working on is a MT-safe reset, in the sense it allows
> for one (1) resetting thread properly synchronize with multiple
> concurrent counter-updating threads.
> 
> It's not going to be completely MT safe, since you can't have two
> threads calling the reset function in parallel.
> 

This is what I meant with "MT-safe reset", so multiple threads not
allowed to call stats reset in parallel.

And for multiple concurrent counter-updating threads case, suggestion is
to stop forwarding.

Above two are the update I added to 'rte_eth_stats_reset()' API, and I
believe we can continue with this restriction for the API.

> Any change to the API should make this clear.
> 
>> For HW stats reset is already reliable and for SW drives offset based
>> approach can make is reliable.
>>
>> Unless you explicitly asked for it, I don't think this is in the agenda
>> of the techboard.
>>
>>


  reply	other threads:[~2024-05-02 14:22 UTC|newest]

Thread overview: 179+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-25 17:46 [RFC] " Ferruh Yigit
2024-04-26 11:33 ` Morten Brørup
2024-04-26 13:37   ` Ferruh Yigit
2024-04-26 14:56     ` Morten Brørup
2024-04-28 15:42   ` Mattias Rönnblom
2024-04-26 14:38 ` [RFC v2] " Ferruh Yigit
2024-04-26 14:47   ` Morten Brørup
2024-04-28 15:11   ` Mattias Rönnblom
2024-05-01 16:19     ` Ferruh Yigit
2024-05-02  5:51       ` Mattias Rönnblom
2024-05-02 14:22         ` Ferruh Yigit [this message]
2024-05-02 15:59           ` Stephen Hemminger
2024-05-02 18:20             ` Ferruh Yigit
2024-05-02 17:37           ` Mattias Rönnblom
2024-05-02 18:26             ` Stephen Hemminger
2024-05-02 21:26               ` Mattias Rönnblom
2024-05-02 21:46                 ` Stephen Hemminger
2024-05-07  7:23     ` Mattias Rönnblom
2024-05-07 13:49       ` Ferruh Yigit
2024-05-07 14:51         ` Stephen Hemminger
2024-05-07 16:00           ` Morten Brørup
2024-05-07 16:54             ` Ferruh Yigit
2024-05-07 18:47               ` Stephen Hemminger
2024-05-08  7:48             ` Mattias Rönnblom
2024-05-08  6:28           ` Mattias Rönnblom
2024-05-08  6:25         ` Mattias Rönnblom
2024-05-07 19:19       ` Morten Brørup
2024-05-08  6:34         ` Mattias Rönnblom
2024-05-08  7:10           ` Morten Brørup
2024-05-08  7:23             ` Mattias Rönnblom
2024-04-26 21:28 ` [RFC] " Patrick Robb
2024-05-03 15:45 ` [RFC v3] " Ferruh Yigit
2024-05-03 22:00   ` Stephen Hemminger
2024-05-07 13:48     ` Ferruh Yigit
2024-05-07 14:52       ` Stephen Hemminger
2024-05-07 17:27         ` Ferruh Yigit
2024-05-08  7:19     ` Mattias Rönnblom
2024-05-08 15:23       ` Stephen Hemminger
2024-05-08 19:48         ` Ferruh Yigit
2024-05-08 20:54           ` Stephen Hemminger
2024-05-09  7:43             ` Morten Brørup
2024-05-09  9:29               ` Bruce Richardson
2024-05-09 11:37                 ` Morten Brørup
2024-05-09 14:19                   ` Morten Brørup
2024-05-10  4:56                     ` Stephen Hemminger
2024-05-10  9:14                       ` Morten Brørup
2024-05-26  7:10                         ` Mattias Rönnblom
2024-05-26  7:07                     ` Mattias Rönnblom
2024-05-26  7:03                   ` Mattias Rönnblom
2024-05-26  7:21         ` Mattias Rönnblom
2024-10-04 17:40           ` Stephen Hemminger
2024-05-07 15:27   ` Morten Brørup
2024-05-07 17:40     ` Ferruh Yigit
2024-05-10  5:01 ` [RFC 0/3] generic sw counters Stephen Hemminger
2024-05-10  5:01   ` [RFC 1/3] ethdev: add internal helper of SW driver statistics Stephen Hemminger
2024-05-10  5:01   ` [RFC 2/3] net/af_packet: use SW stats helper Stephen Hemminger
2024-05-10  5:01   ` [RFC 3/3] net/tap: use generic SW stats Stephen Hemminger
2024-05-10 17:29   ` [RFC 0/3] generic sw counters Morten Brørup
2024-05-10 19:30     ` Stephen Hemminger
2024-05-13 18:52   ` [RFC v2 0/7] generic SW counters Stephen Hemminger
2024-05-13 18:52     ` [RFC v2 1/7] eal: generic 64 bit counter Stephen Hemminger
2024-05-13 19:36       ` Morten Brørup
2024-05-13 18:52     ` [RFC v2 2/7] ethdev: add internal helper of SW driver statistics Stephen Hemminger
2024-05-13 18:52     ` [RFC v2 3/7] net/af_packet: use SW stats helper Stephen Hemminger
2024-05-13 18:52     ` [RFC v2 4/7] net/tap: use generic SW stats Stephen Hemminger
2024-05-13 18:52     ` [RFC v2 5/7] net/pcap: " Stephen Hemminger
2024-05-13 18:52     ` [RFC v2 6/7] net/af_xdp: " Stephen Hemminger
2024-05-13 18:52     ` [RFC v2 7/7] net/ring: " Stephen Hemminger
2024-05-14 15:35   ` [PATCH v3 0/7] Generic SW counters Stephen Hemminger
2024-05-14 15:35     ` [PATCH v3 1/7] eal: generic 64 bit counter Stephen Hemminger
2024-05-15  9:30       ` Morten Brørup
2024-05-15 15:03         ` Stephen Hemminger
2024-05-15 16:18           ` Morten Brørup
2024-05-26  7:34         ` Mattias Rönnblom
2024-05-26  6:45       ` Mattias Rönnblom
2024-05-14 15:35     ` [PATCH v3 2/7] ethdev: add internal helper of SW driver statistics Stephen Hemminger
2024-05-14 15:35     ` [PATCH v3 3/7] net/af_packet: use SW stats helper Stephen Hemminger
2024-05-14 15:35     ` [PATCH v3 4/7] net/af_xdp: use generic SW stats Stephen Hemminger
2024-05-14 15:35     ` [PATCH v3 5/7] net/pcap: " Stephen Hemminger
2024-05-14 15:35     ` [PATCH v3 6/7] net/ring: " Stephen Hemminger
2024-05-14 15:35     ` [PATCH v3 7/7] net/tap: " Stephen Hemminger
2024-05-15 23:40   ` [PATCH v4 0/8] Generic 64 bit counters for SW PMD's Stephen Hemminger
2024-05-15 23:40     ` [PATCH v4 1/8] eal: generic 64 bit counter Stephen Hemminger
2024-05-15 23:40     ` [PATCH v4 2/8] ethdev: add common counters for statistics Stephen Hemminger
2024-05-15 23:40     ` [PATCH v4 3/8] net/af_packet: use generic SW stats Stephen Hemminger
2024-05-15 23:40     ` [PATCH v4 4/8] net/af_xdp: " Stephen Hemminger
2024-05-15 23:40     ` [PATCH v4 5/8] net/pcap: " Stephen Hemminger
2024-05-15 23:40     ` [PATCH v4 6/8] net/ring: " Stephen Hemminger
2024-05-15 23:40     ` [PATCH v4 7/8] net/tap: " Stephen Hemminger
2024-05-15 23:41     ` [PATCH v4 8/8] net/null: " Stephen Hemminger
2024-05-16 15:40   ` [PATCH v5 0/9] Generic 64 bit counters Stephen Hemminger
2024-05-16 15:40     ` [PATCH v5 1/9] eal: generic 64 bit counter Stephen Hemminger
2024-05-16 18:22       ` Wathsala Wathawana Vithanage
2024-05-16 21:42         ` Stephen Hemminger
2024-05-17  2:39           ` Honnappa Nagarahalli
2024-05-17  3:29             ` Stephen Hemminger
2024-05-17  4:39               ` Honnappa Nagarahalli
2024-05-16 15:40     ` [PATCH v5 2/9] ethdev: add common counters for statistics Stephen Hemminger
2024-05-16 18:30       ` Wathsala Wathawana Vithanage
2024-05-17  0:19         ` Stephen Hemminger
2024-05-16 15:40     ` [PATCH v5 3/9] net/af_packet: use generic SW stats Stephen Hemminger
2024-05-16 15:40     ` [PATCH v5 4/9] net/af_xdp: " Stephen Hemminger
2024-05-16 15:40     ` [PATCH v5 5/9] net/pcap: " Stephen Hemminger
2024-05-16 15:40     ` [PATCH v5 6/9] test/pmd_ring: initialize mbufs Stephen Hemminger
2024-05-16 15:40     ` [PATCH v5 7/9] net/ring: use generic SW stats Stephen Hemminger
2024-05-16 15:40     ` [PATCH v5 8/9] net/tap: " Stephen Hemminger
2024-05-16 15:40     ` [PATCH v5 9/9] net/null: " Stephen Hemminger
2024-05-17  0:12   ` [PATCH v6 0/9] Generic 64 bit counters for SW drivers Stephen Hemminger
2024-05-17  0:12     ` [PATCH v6 1/9] eal: generic 64 bit counter Stephen Hemminger
2024-05-17  2:45       ` Honnappa Nagarahalli
2024-05-17  3:30         ` Stephen Hemminger
2024-05-17  4:26           ` Honnappa Nagarahalli
2024-05-17  6:44             ` Morten Brørup
2024-05-17 15:05               ` Stephen Hemminger
2024-05-17 16:18               ` Stephen Hemminger
2024-05-18 14:00                 ` Morten Brørup
2024-05-19 15:13                   ` Stephen Hemminger
2024-05-19 17:10                     ` Morten Brørup
2024-05-19 22:49                       ` Stephen Hemminger
2024-05-20  7:57                         ` Morten Brørup
2024-05-17 15:07             ` Stephen Hemminger
2024-05-17  0:12     ` [PATCH v6 2/9] ethdev: add common counters for statistics Stephen Hemminger
2024-05-17  0:12     ` [PATCH v6 3/9] net/af_packet: use generic SW stats Stephen Hemminger
2024-05-17  0:12     ` [PATCH v6 4/9] net/af_xdp: " Stephen Hemminger
2024-05-17 13:34       ` Loftus, Ciara
2024-05-17 14:54         ` Stephen Hemminger
2024-05-17  0:12     ` [PATCH v6 5/9] net/pcap: " Stephen Hemminger
2024-05-17  0:12     ` [PATCH v6 6/9] test/pmd_ring: initialize mbufs Stephen Hemminger
2024-05-17  0:12     ` [PATCH v6 7/9] net/ring: use generic SW stats Stephen Hemminger
2024-05-17  0:12     ` [PATCH v6 8/9] net/tap: " Stephen Hemminger
2024-05-17  0:12     ` [PATCH v6 9/9] net/null: " Stephen Hemminger
2024-05-17 17:35   ` [PATCH v7 0/9] Use weak atomic operations for SW PMD counters Stephen Hemminger
2024-05-17 17:35     ` [PATCH v7 1/9] eal: generic 64 bit counter Stephen Hemminger
2024-05-17 17:35     ` [PATCH v7 2/9] ethdev: add common counters for statistics Stephen Hemminger
2024-05-17 17:35     ` [PATCH v7 3/9] net/af_packet: use generic SW stats Stephen Hemminger
2024-05-17 17:35     ` [PATCH v7 4/9] net/af_xdp: " Stephen Hemminger
2024-05-17 17:35     ` [PATCH v7 5/9] net/pcap: " Stephen Hemminger
2024-05-17 17:35     ` [PATCH v7 6/9] test/pmd_ring: initialize mbufs Stephen Hemminger
2024-05-17 17:35     ` [PATCH v7 7/9] net/ring: use generic SW stats Stephen Hemminger
2024-05-17 17:35     ` [PATCH v7 8/9] net/tap: " Stephen Hemminger
2024-05-17 17:35     ` [PATCH v7 9/9] net/null: " Stephen Hemminger
2024-05-21 17:00   ` [PATCH v8 0/8] Common statistics routines for SW based PMD's Stephen Hemminger
2024-05-21 17:00     ` [PATCH v8 1/8] eal: generic 64 bit counter Stephen Hemminger
2024-05-21 17:00     ` [PATCH v8 2/8] ethdev: add common counters for statistics Stephen Hemminger
2024-05-21 17:00     ` [PATCH v8 3/8] net/af_packet: use generic SW stats Stephen Hemminger
2024-05-21 17:00     ` [PATCH v8 4/8] net/af_xdp: " Stephen Hemminger
2024-05-21 17:00     ` [PATCH v8 5/8] net/pcap: " Stephen Hemminger
2024-05-21 17:00     ` [PATCH v8 6/8] net/ring: " Stephen Hemminger
2024-05-21 17:00     ` [PATCH v8 7/8] net/tap: " Stephen Hemminger
2024-05-21 17:00     ` [PATCH v8 8/8] net/null: " Stephen Hemminger
2024-05-21 20:16   ` [PATCH v9 0/8] Common statistics for SW PMD's Stephen Hemminger
2024-05-21 20:16     ` [PATCH v9 1/8] eal: generic 64 bit counter Stephen Hemminger
2024-05-22  8:31       ` Morten Brørup
2024-05-22 15:33         ` Stephen Hemminger
2024-05-22 18:09           ` Morten Brørup
2024-05-22 19:53             ` Stephen Hemminger
2024-05-22 20:56               ` Morten Brørup
2024-05-22 15:37         ` Stephen Hemminger
2024-05-22 17:57           ` Morten Brørup
2024-05-22 19:01             ` Tyler Retzlaff
2024-05-22 19:51               ` Stephen Hemminger
2024-05-26 14:46                 ` Mattias Rönnblom
2024-05-26 14:39               ` Mattias Rönnblom
2024-05-21 20:16     ` [PATCH v9 2/8] ethdev: add common counters for statistics Stephen Hemminger
2024-05-21 20:16     ` [PATCH v9 3/8] net/af_packet: use generic SW stats Stephen Hemminger
2024-05-21 20:16     ` [PATCH v9 4/8] net/af_xdp: " Stephen Hemminger
2024-05-21 20:16     ` [PATCH v9 5/8] net/pcap: " Stephen Hemminger
2024-05-21 20:16     ` [PATCH v9 6/8] net/ring: " Stephen Hemminger
2024-05-21 20:16     ` [PATCH v9 7/8] net/tap: " Stephen Hemminger
2024-05-21 20:16     ` [PATCH v9 8/8] net/null: " Stephen Hemminger
2024-05-22 16:12   ` [PATCH v10 0/8] Common statistics for software PMD's Stephen Hemminger
2024-05-22 16:12     ` [PATCH v10 1/8] eal: generic 64 bit counter Stephen Hemminger
2024-05-22 16:12     ` [PATCH v10 2/8] ethdev: add common counters for statistics Stephen Hemminger
2024-05-22 16:12     ` [PATCH v10 3/8] net/af_packet: use generic SW stats Stephen Hemminger
2024-05-22 16:12     ` [PATCH v10 4/8] net/af_xdp: " Stephen Hemminger
2024-05-22 16:12     ` [PATCH v10 5/8] net/pcap: " Stephen Hemminger
2024-05-22 16:12     ` [PATCH v10 6/8] net/ring: " Stephen Hemminger
2024-05-22 16:12     ` [PATCH v10 7/8] net/tap: " Stephen Hemminger
2024-05-22 16:12     ` [PATCH v10 8/8] net/null: " Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=422dd5a6-4ed6-4ae5-b613-b22a7cf6f77d@amd.com \
    --to=ferruh.yigit@amd.com \
    --cc=dev@dpdk.org \
    --cc=hofors@lysator.liu.se \
    --cc=linville@tuxdriver.com \
    --cc=mattias.ronnblom@ericsson.com \
    --cc=mb@smartsharesystems.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).