From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9F4C6A00BE; Thu, 17 Feb 2022 12:10:49 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C0F4841156; Thu, 17 Feb 2022 12:10:47 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 1108941154 for ; Thu, 17 Feb 2022 12:10:46 +0100 (CET) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 88A3844; Thu, 17 Feb 2022 14:10:45 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 88A3844 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1645096245; bh=3V+CSu3Nd/nsbanjwyPmoFiCVyi3WRR7k8+GxrSEKN8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=vz4JeYNO5yzMzaFTIMexTZYm9IpD5RvPy14HZ5d2UFjvxZTWJWePyqjCMzYy4NJRu 5ERfw1JYwWgMdbQhGS2E2FwJ1pCRa+KIuN3IydKWByaRfztob2814LvIphVuntS3UJ ID/6uurTrnN37ev6pDb+fQPTH+p9ICgoPPjYD3sc= Message-ID: <7e9f1897-de40-07d3-c480-a46ca45a8c90@oktetlabs.ru> Date: Thu, 17 Feb 2022 14:10:45 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v5 03/10] ethdev: bring in async queue-based flow rules operations Content-Language: en-US To: Ori Kam , Alexander Kozyrev , "dev@dpdk.org" Cc: "NBU-Contact-Thomas Monjalon (EXTERNAL)" , "ivan.malov@oktetlabs.ru" , "ferruh.yigit@intel.com" , "mohammad.abdul.awal@intel.com" , "qi.z.zhang@intel.com" , "jerinj@marvell.com" , "ajit.khaparde@broadcom.com" , "bruce.richardson@intel.com" References: <20220209213809.1208269-1-akozyrev@nvidia.com> <20220211022653.1372318-1-akozyrev@nvidia.com> <20220211022653.1372318-4-akozyrev@nvidia.com> <6eac9cbe-cebf-f33f-eabd-79a4375916b6@oktetlabs.ru> <71bd0d78-d5b3-6692-f66f-95b4114853fb@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2/16/22 18:15, Ori Kam wrote: > Hi Andew, > > I missed on comments PSB, > >> -----Original Message----- >> From: Andrew Rybchenko >> 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 : >>>> 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. > 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.