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. 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. Best, Ori
