Hi Andrew, > -----Original Message----- > From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru> > Sent: Thursday, February 17, 2022 1:11 PM > Subject: Re: [PATCH v5 03/10] ethdev: bring in async queue-based flow rules > operations > > On 2/16/22 18:15, Ori Kam wrote: > > Hi Andew, > > > > I missed on comments PSB, > > > >> -----Original Message----- > >> From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru> > >> Subject: Re: [PATCH v5 03/10] ethdev: bring in async queue-based flow > >> rules operations > >> > >> On 2/12/22 05:19, Alexander Kozyrev wrote: > >>> On Fri, Feb 11, 2022 7:42 Andrew Rybchenko > >>> <andrew.rybche...@oktetlabs.ru>: > >>>> On 2/11/22 05:26, Alexander Kozyrev wrote: > >>>>> A new, faster, queue-based flow rules management mechanism is needed > > > > [Snip] > > > > > >>>>> + > >>>>> +- Operations can be postponed and pushed to NIC in batches. > >>>>> + > >>>>> +- Results pulling must be done on time to avoid queue overflows. > >>>> > >>>> polling? (as libc poll() which checks status of file descriptors) > >>>> it is not pulling the door to open it :) > >>> > >>> poll waits for some event on a file descriptor as it title says. > >>> And then user has to invoke read() to actually get any info from the fd. > >>> The point of our function is to return the result immediately, thus > >>> pulling. > >>> We had many names appearing in the thread for these functions. > >>> As we know, naming variables is the second hardest thing in programming. > >>> I wanted this pull for results pulling be a counterpart for the push for > >>> pushing the operations to a NIC. Another idea is pop/push pair, but they > >>> are > >>> more like for operations only, not for results. > >>> Having said that I'm at the point of accepting any name here. > >> > >> I agree that it is hard to choose good naming. > >> Just want to say that polling is not alway waiting. > >> > >> poll - check the status of (a device), especially as part of a repeated > >> cycle. > >> > >> Here we're checking status of flow engine requests and yes, > >> finally in a repeated cycle. > >> > > I think the best name should be dequeue since it means that > > the calling app gets back info and also free space in the the qeueue. > > Dequeue is bad since it is not a queue because of out-of-order > completions. So, if it is a ring, completion of one request > does not always free space in ring. May be it should not be > treated as a ring. > Like I said I'm O.K with the pull version. I had many many descussions about the queue, I was also thinking about it the way you do, that saying queue means it is ordered, but that is not true by definition you can have unordered queue. (for example priority queues) or just your everyday queue in the store that at the end will be split to counters and each customer can finish before the one that he was after in the queue.
Important thing to notice, this function does clear space in the queue. > > My second option is the pull, since again it implies that we are getting > > back > > something from the queue and not just waiting for event. > > I'll think a bit more about it. Thanks, Best, Ori
