<!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/18 17:05, Konstantin Ananyev wrote: </div> <blockquote type="cite" cite="mid:cc47fed3fc9c4895ac564539ce867daf@huawei.com"> <pre class="moz-quote-pre" wrap=""> </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> On 2023/8/17 22:06, Stephen Hemminger wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">On Thu, 17 Aug 2023 05:06:20 +0000 Honnappa Nagarahalli <a class="moz-txt-link-rfc2396E" href="mailto:Honnappa.Nagarahalli@arm.com"><Honnappa.Nagarahalli@arm.com></a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Hi Matan, Viacheslav, Tyler pointed out that the function __mlx5_hws_cnt_pool_enqueue_revert is accessing the ring private structure members </pre> </blockquote> </blockquote> <pre class="moz-quote-pre" wrap="">(prod.head and prod.tail) directly. Even though ' struct rte_ring' is a public structure (mainly because the library provides inline functions), the structure members are considered private to the ring library. So, this needs to be corrected. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> It looks like the function __mlx5_hws_cnt_pool_enqueue_revert is trying to revert things that were enqueued. It is not clear to </pre> </blockquote> </blockquote> <pre class="moz-quote-pre" wrap="">me why this functionality is required. Can you provide the use case for this? We can discuss possible solutions. </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">How can reverting be thread safe? Consumer could have already looked at them? </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Hey, In our case, this ring is SC/SP, only accessed by one thread (enqueue/dequeue/revert). The scenario we have "revert" is: We use ring to manager our HW objects (counter in this case) and for each core (thread) has "cache" (a SC/SP ring) for sake of performance. 1. Get objects from "cache" firstly, if cache is empty, we fetch a bulk of free objects from global ring into cache. 2. Put (free) objects also into "cache" firstly, if cache is full, we flush a bulk of objects into global ring in order to make some rooms in cache. However, this HW object cannot be immediately reused after free. It needs time to be reset and then can be used again. So when we flush cache, we want to keep the first enqueued objects still stay there because they have more chance already be reset than the latest enqueued objects. Only flush recently enqueued objects back into global ring, act as "LIFO" behavior. This is why we require "revert" enqueued objects. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Wouldn't then simple stack fit you better? Something like lib/stack/rte_stack_std.h, but even without spinlock around? </pre> </blockquote> No, stack is always a "LIFO" struct, right? 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. 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. In short, we require a struct supports "FIFO" and "LIFO". -Jack <blockquote type="cite" cite="mid:cc47fed3fc9c4895ac564539ce867daf@huawei.com"> <pre class="moz-quote-pre" wrap=""> </pre> </blockquote> </body> <lt-container></lt-container> </html>