From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f68.google.com (mail-pg0-f68.google.com [74.125.83.68]) by dpdk.org (Postfix) with ESMTP id 11A861EE2F for ; Wed, 13 Jun 2018 12:11:30 +0200 (CEST) Received: by mail-pg0-f68.google.com with SMTP id w12-v6so1045588pgc.6 for ; Wed, 13 Jun 2018 03:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=mzGAwT5bEarmdDqb4aJjn/PJ1pT7itmSSkEkKl3Teu0=; b=PAyXUPBrDUMyytYfNLeDxeSMU9Pnvb5EIZnAR+jt+GhrWYLomzIsOhG2pxfX+Pcz8O 4+4sOJsxZu09xF1mOOWaYZcRavMX9RjFjwX1GHQ7FIcJmls5LxWpo2R7hViYmXw/qCG6 lor9RHObu2B9jtaSZd3QB3G9zyt3ZyaQNzDFTVijsslby428xKz5VzfrO+Cohi8bJDNL AxkbD/3Yfowov6lQSzbO7KViQN7BegINeOvDAcxqMXg8QC23XkB8zUr9Lqfq17YgpWll kKQ20UxEKBVLXRiXny6CBgRFPc+hgfzVSTO8p+wJjHXcbUvjm3x81TA72Euqt38qREDf 6OLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=mzGAwT5bEarmdDqb4aJjn/PJ1pT7itmSSkEkKl3Teu0=; b=L6abYK+btl50EuXkm9gK1nio/R+f3cc/2yU/hBiNN68OT07g8ef5Wzq6SLHV2/Uh4w BHa7gUBXbDvyxeXZWykFXNFjnMPwVdZmGiiemM+WYSPcxxTGWcKK+Fl+E8/5d//ykTAM 24tdlkHAHnwfPeFYLhWO5932ijD4pLrQTLsrn+fImyQe8w+akris8vUI/ApfBjQb10aF hmTH9pu9EN3EbwaSNNWhK18grtY/4AqvIyUK43yLM0Ny0wwA2EYSvM+nsghZmDZBnK/K tRwxHH8wBH0s5UkjqYequewWW8Vs+43WqLe52HCiO6xoCN8XK3q6D2q+EyP2uz2xzOFw ZCMA== X-Gm-Message-State: APt69E36Jk2XJw8MYcPprDOipyWojgezMWzGN2NvdzNfrAQv+KufjsS2 WTtfQ6hBsNE6vFKIZoTWAOz4Tw== X-Google-Smtp-Source: ADUXVKIqonMkSCyKzSqGJZpdCNvIDo2LdwT3c78be0rRPECtyBD6GY7/igyHaE1KHXcCHYh4paTqig== X-Received: by 2002:a62:e70e:: with SMTP id s14-v6mr4276792pfh.131.1528884689104; Wed, 13 Jun 2018 03:11:29 -0700 (PDT) Received: from localhost (31-172-191-173.noc.fibertech.net.pl. [31.172.191.173]) by smtp.gmail.com with ESMTPSA id 29-v6sm3881951pfj.14.2018.06.13.03.11.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 03:11:27 -0700 (PDT) Date: Wed, 13 Jun 2018 12:11:24 +0200 From: Tomasz Duszynski To: "De Lara Guarch, Pablo" Cc: Tomasz Duszynski , "Doherty, Declan" , "akhil.goyal@nxp.com" , "ravi1.kumar@amd.com" , "jerin.jacob@caviumnetworks.com" , "Zhang, Roy Fan" , "Trahe, Fiona" , "jianjay.zhou@huawei.com" , "dev@dpdk.org" Message-ID: <20180613101124.GC1913@sh> References: <20180608220234.10170-1-pablo.de.lara.guarch@intel.com> <20180608220234.10170-4-pablo.de.lara.guarch@intel.com> <20180612113736.GA1913@sh> <20180613061137.GB1913@sh> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH 3/6] cryptodev: remove max number of sessions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 10:11:30 -0000 On Wed, Jun 13, 2018 at 08:23:36AM +0000, De Lara Guarch, Pablo wrote: > Hi Tomasz, > > > -----Original Message----- > > From: Tomasz Duszynski [mailto:tdu@semihalf.com] > > Sent: Wednesday, June 13, 2018 7:12 AM > > To: De Lara Guarch, Pablo > > Cc: Tomasz Duszynski ; Doherty, Declan > > ; akhil.goyal@nxp.com; ravi1.kumar@amd.com; > > jerin.jacob@caviumnetworks.com; Zhang, Roy Fan ; > > Trahe, Fiona ; jianjay.zhou@huawei.com; > > dev@dpdk.org > > Subject: Re: [PATCH 3/6] cryptodev: remove max number of sessions > > > > On Tue, Jun 12, 2018 at 01:53:36PM +0000, De Lara Guarch, Pablo wrote: > > > > > > > > > > -----Original Message----- > > > > From: Tomasz Duszynski [mailto:tdu@semihalf.com] > > > > Sent: Tuesday, June 12, 2018 12:38 PM > > > > To: De Lara Guarch, Pablo > > > > Cc: Doherty, Declan ; akhil.goyal@nxp.com; > > > > ravi1.kumar@amd.com; jerin.jacob@caviumnetworks.com; Zhang, Roy Fan > > > > ; Trahe, Fiona ; > > > > tdu@semihalf.com; jianjay.zhou@huawei.com; dev@dpdk.org > > > > Subject: Re: [PATCH 3/6] cryptodev: remove max number of sessions > > > > > > > > Hello Pablo, > > > > > > > > On Fri, Jun 08, 2018 at 11:02:31PM +0100, Pablo de Lara wrote: > > > > > Sessions are not created and stored in the crypto device anymore, > > > > > since now the session mempool is created at the application level. > > > > > > > > > > Therefore the limitation of the maximum number of sessions that > > > > > can be created should not be dependent of the crypto device. > > > > > > > > > > Signed-off-by: Pablo de Lara > > > > > > ... > > > > > > > > diff --git a/drivers/crypto/mvsam/rte_mrvl_pmd.c > > > > b/drivers/crypto/mvsam/rte_mrvl_pmd.c > > > > > index 1b6029a56..822b6cac7 100644 > > > > > --- a/drivers/crypto/mvsam/rte_mrvl_pmd.c > > > > > +++ b/drivers/crypto/mvsam/rte_mrvl_pmd.c > > > > > @@ -719,7 +719,6 @@ cryptodev_mrvl_crypto_create(const char *name, > > > > > internals =3D dev->data->dev_private; > > > > > > > > > > internals->max_nb_qpairs =3D init_params->max_nb_queue_pairs; > > > > > - internals->max_nb_sessions =3D init_params->max_nb_sessions; > > > > > > > > > > /* > > > > > * ret =3D=3D -EEXIST is correct, it means DMA @@ -734,8 +733,6= @@ > > > > > cryptodev_mrvl_crypto_create(const char *name, > > > > > "DMA memory has been already initialized by a > > > > different driver."); > > > > > } > > > > > > > > > > - sam_params.max_num_sessions =3D internals->max_nb_sessions; > > > > > > > > This will not fly since library maintains separate list of sessions. > > > > We have to initialize this number to something sane. Since we cannot > > > > get it from userspace perhaps make that compile-time configurable by > > > > adding separate CONFIG_? > > > > > > Hi Tomasz, > > > > > > If you need to have an actual limit, you could define it internally > > > (not adding an external configuration option), but bear in mind that > > > This won't prevent an application from trying to allocate more sessio= ns. > > > > You can define arbitrary number of session on condition you have enough > > memory. So no hard limit here. What bothers me is the case where app wa= nts to > > initialize more session than the library internally has. > > If this happens userspace will get an error. On the other hand requesti= ng some > > arbitrary large number of session from library and hoping app will neve= r use so > > many wastes memory (which might be valuable on resource constrained > > systems). > > > > That is why keeping the number of sessions in app and library in sync is > > important. > > > > Do we have any option in DPDK now to workaround this? > > Ok I see, so actually the MUSDK library needs a maximum number of session= s. > I'd say then we should keep this field, but we can add a special case: 0. > In this case, the PMD does not have any maximum number of sessions > (which would be applicable to most PMDs). > > So, for this PMD, this special case is not supported. If 0 is passed, > either return that unlimited number of sessions is not supported, > or set it to a default value (defined inside the PMD, such as 2048). > If no value is passed, this number can be set to the default value too. > > How does this sound? Who is going to pass that value? App? Or the old way is retained i.e PMD parameters? OK, my understanding is that we have 3 options: 1. 0 is passed which for most of the drivers translates to "you should not care about sessions number created by userspace application". In case PMD supports that it returns either success or failure. 2. Nothing is passed which means PMD should not care about number of sessions except mvsam which sets some default value. 3. Passing some arbitrary value which which sets number of sessions for PMDs that care about that (mvsam). In that case app would respect that number and not allocate more than specified? This is what DPDK has now. Right? Doesn't is sound like the mechanism that gets removed from DPDK with some extra handling added? Other solution might be to remove the old API as planned and change the PMD itself so that it defers library initialization until PMD is started. During session configuration necessary information would be saved and reused later on (i.e during PMD start). > > Thanks, > Pablo > > > > > > > > > > If your PMD has a limitation on the maximum number of sessions, then > > > maybe this change won't work for you (removing the maximum number of > > sessions), so let me know and we can discuss this. > > > > > > Thanks, > > > Pablo > > > > > > P.S. Please, next time, strip out the code that you are not > > > commenting, as it was hard to find this question :) > > > > > > > -- > > - Tomasz Duszy=C5=84ski -- - Tomasz Duszy=C5=84ski