<!DOCTYPE html><html data-lt-installed="true"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="padding-bottom: 1px;">
<div class="moz-cite-prefix">On 2023/8/19 19:57, Konstantin Ananyev
wrote:<br>
</div>
<blockquote type="cite" cite="mid:9850f8f4-bc5b-3af7-c538-99a26aab6d9c@yandex.ru">18/08/2023
10:38, Jack Min пишет:
<br>
<blockquote type="cite">On 2023/8/18 17:05, Konstantin Ananyev
wrote:
<br>
<blockquote type="cite">
<blockquote type="cite">On 2023/8/17 22:06, Stephen Hemminger
wrote:
<br>
<blockquote type="cite">On Thu, 17 Aug 2023 05:06:20 +0000
<br>
Honnappa Nagarahalli<a class="moz-txt-link-rfc2396E" href="mailto:Honnappa.Nagarahalli@arm.com"><Honnappa.Nagarahalli@arm.com></a>
wrote:
<br>
<br>
<blockquote type="cite">Hi Matan, Viacheslav,
<br>
Tyler pointed out that the function
__mlx5_hws_cnt_pool_enqueue_revert is accessing the ring
private structure members
<br>
</blockquote>
</blockquote>
(prod.head and prod.tail) directly. Even though ' struct
rte_ring' is a public structure (mainly because the library
provides inline
<br>
functions), the structure members are considered private to
the ring library. So, this needs to be corrected.
<br>
<blockquote type="cite">
<blockquote type="cite">It looks like the function
__mlx5_hws_cnt_pool_enqueue_revert is trying to revert
things that were enqueued. It is not clear to
<br>
</blockquote>
</blockquote>
me why this functionality is required. Can you provide the
use case for this? We can discuss possible solutions.
<br>
<blockquote type="cite">How can reverting be thread safe?
Consumer could have already looked at them?
<br>
</blockquote>
Hey,
<br>
<br>
In our case, this ring is SC/SP, only accessed by one thread
<br>
(enqueue/dequeue/revert).
<br>
<br>
The scenario we have "revert" is:
<br>
<br>
We use ring to manager our HW objects (counter in this
case) and for
<br>
each core (thread) has "cache" (a SC/SP ring) for sake of
performance.
<br>
<br>
1. Get objects from "cache" firstly, if cache is empty, we
fetch a bulk
<br>
of free objects from global ring into cache.
<br>
<br>
2. Put (free) objects also into "cache" firstly, if cache is
full, we
<br>
flush a bulk of objects into global ring in order to make
some rooms in
<br>
cache.
<br>
<br>
However, this HW object cannot be immediately reused after
free. It
<br>
needs time to be reset and then can be used again.
<br>
<br>
So when we flush cache, we want to keep the first enqueued
objects still
<br>
stay there because they have more chance already be reset
than the
<br>
latest enqueued objects.
<br>
<br>
Only flush recently enqueued objects back into global ring,
act as
<br>
"LIFO" behavior.
<br>
<br>
This is why we require "revert" enqueued objects.
<br>
<br>
</blockquote>
Wouldn't then simple stack fit you better?
<br>
Something like lib/stack/rte_stack_std.h, but even without
spinlock around?
<br>
</blockquote>
<br>
No, stack is always a "LIFO" struct, right?
<br>
</blockquote>
<br>
Yep.
<br>
<br>
<blockquote type="cite">
<br>
Here first we need this cache works as "FIFO" in most cases
(get/put) because the first enqueued objects have more chance
that are already reset so can reuse them.
<br>
<br>
We only require "LIFO" behavior when "flush" cache in order to
make some room, so next free will be quick because it happens in
our local cache, needn't access global ring.
<br>
<br>
In short, we require a struct supports "FIFO" and "LIFO".
<br>
</blockquote>
<br>
Ok, thanks fro explanation.
<br>
So you need a ring, but with an ability to revert prod N elements
back, right?
<br>
</blockquote>
<br>
Yes, exactly!<br>
</body>
<lt-container></lt-container>
</html>