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 F1D03A0032; Mon, 18 Jul 2022 15:05:03 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 891E24069F; Mon, 18 Jul 2022 15:05:03 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id AF5C840041 for ; Mon, 18 Jul 2022 15:05:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658149501; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=X41/yoefiIvm91BmUETPCU5lKBE4od5lIBvGi8kKBD0=; b=X2rbsC1h2/+MM1cx3xOCp7sMv4QHjEyvcOk1tZ8+eMurYdGr8281pqVvX6OnAvmTfkD2tL 8jjMOe6JYGh9cttMhaQnatpgVX1J1HZt+wmy7PJjtmRadOfLui5CldRAiPAmZzP5q9KTLE SvdMlWvBRdFfvLszmIHF8+VMOQ3s6TY= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-58-TpKV7LCxMiWui7Yc3YGTfw-1; Mon, 18 Jul 2022 09:04:54 -0400 X-MC-Unique: TpKV7LCxMiWui7Yc3YGTfw-1 Received: by mail-qt1-f197.google.com with SMTP id a18-20020a05622a02d200b0031ed7ae9abeso6862728qtx.8 for ; Mon, 18 Jul 2022 06:04:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=X41/yoefiIvm91BmUETPCU5lKBE4od5lIBvGi8kKBD0=; b=L9b44wITCeCjjkB3nvZOmL9nFRrJ7QVasWqKcjazESW4PTgeimB+4YAf2nSwI5ajsx HIQS77b7iy9RAdebtB8TYIRloAKxAKXqF55qIw+8fG8+Lw8FBJWi6kpqzKUgL6+I5uxg jKSwfk7RsDT8lKuDwMWV+Eq14NnRuN+8hWKBAUuZodGGbjcIshyRxXeR7UcjsSCko7UB MiZlNkTGi7dax09ODvi5Nf6tuOaeQX71BWMjYj1Xovk6CnN0SHA8DH47BNE6vMcnSNcY sJv5r2/SDgInPW5wn55slwRiUPtQhlTMY7Le/0lf9PVEJnDXqERIHKMFo+WQGcc+YVVa RPKQ== X-Gm-Message-State: AJIora/8Ls1mVdr6vCvlaDy2h5YOKryYXVWhB+HhIphRC1lFbJgWu/m4 D7gju1z+ZdynoN1oyJzvFuosvlEafxzcmr1GZsiblN1nTfnslp0F06zb7685dGlyUNHRoTbEJhj 0EaU= X-Received: by 2002:a05:622a:1753:b0:31e:e98d:71a3 with SMTP id l19-20020a05622a175300b0031ee98d71a3mr6599093qtk.81.1658149493625; Mon, 18 Jul 2022 06:04:53 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vlqEvZ0NDI8c0i2IXQjSC09dFVFfwR2R46qoUrGy5stOmphxy+BTudJ6vFTRMnfjPVZsViyA== X-Received: by 2002:a05:622a:1753:b0:31e:e98d:71a3 with SMTP id l19-20020a05622a175300b0031ee98d71a3mr6599068qtk.81.1658149493338; Mon, 18 Jul 2022 06:04:53 -0700 (PDT) Received: from localhost.localdomain (024-205-208-113.res.spectrum.com. [24.205.208.113]) by smtp.gmail.com with ESMTPSA id f13-20020a05620a408d00b006b5df4d2c81sm6163942qko.94.2022.07.18.06.04.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Jul 2022 06:04:52 -0700 (PDT) Subject: Re: [PATCH v4 3/7] bbdev: add device info on queue topology To: "Chautru, Nicolas" , "dev@dpdk.org" , "thomas@monjalon.net" , "gakhil@marvell.com" , "hemant.agrawal@nxp.com" Cc: "maxime.coquelin@redhat.com" , "mdr@ashroe.eu" , "Richardson, Bruce" , "david.marchand@redhat.com" , "stephen@networkplumber.org" References: <1655491040-183649-6-git-send-email-nicolas.chautru@intel.com> <1657067022-54373-1-git-send-email-nicolas.chautru@intel.com> <1657067022-54373-4-git-send-email-nicolas.chautru@intel.com> <36d168b0-6bbf-b393-2f22-7b2968926cf5@redhat.com> From: Tom Rix Message-ID: <3dcd2989-52e9-8df2-b82a-132eb8b1980b@redhat.com> Date: Mon, 18 Jul 2022 06:04:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=trix@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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 7/7/22 10:13 AM, Chautru, Nicolas wrote: > Hi Tom, > >> -----Original Message----- >> From: Tom Rix >> Sent: Thursday, July 7, 2022 6:34 AM >> To: Chautru, Nicolas ; dev@dpdk.org; >> thomas@monjalon.net; gakhil@marvell.com; hemant.agrawal@nxp.com >> Cc: maxime.coquelin@redhat.com; mdr@ashroe.eu; Richardson, Bruce >> ; david.marchand@redhat.com; >> stephen@networkplumber.org >> Subject: Re: [PATCH v4 3/7] bbdev: add device info on queue topology >> >> >> On 7/6/22 2:12 PM, Chautru, Nicolas wrote: >>> Hi Tom, >>> >>>> -----Original Message----- >>>> From: Tom Rix >>>> Subject: Re: [PATCH v4 3/7] bbdev: add device info on queue topology >>>> >>>> >>>> On 7/5/22 5:23 PM, Nicolas Chautru wrote: >>>>> Adding more options in the API to expose the number of queues >>>>> exposed and related priority. >>>>> >>>>> Signed-off-by: Nicolas Chautru >>>>> --- >>>>> lib/bbdev/rte_bbdev.h | 4 ++++ >>>>> 1 file changed, 4 insertions(+) >>>>> >>>>> diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index >>>>> 9b1ffa4..ac941d6 100644 >>>>> --- a/lib/bbdev/rte_bbdev.h >>>>> +++ b/lib/bbdev/rte_bbdev.h >>>>> @@ -289,6 +289,10 @@ struct rte_bbdev_driver_info { >>>>> >>>>> /** Maximum number of queues supported by the device */ >>>>> unsigned int max_num_queues; >>>>> + /** Maximum number of queues supported per operation type */ >>>>> + unsigned int num_queues[RTE_BBDEV_OP_TYPE_PADDED_MAX]; >>>>> + /** Priority level supported per operation type */ >>>>> + unsigned int queue_priority[RTE_BBDEV_OP_TYPE_PADDED_MAX]; >>>> It is better to add new elements to the end of a structure for better >>>> backward compatibility >>> All that serie is not ABI compatible (sizes change etc...). I don’t believe there >> is such a recommendation, is there? >> >> Depends on what users expect, a dynamically linked old application would at >> best core here.  If the elements were added to the end, yes the size would >> change but the old dynamically linked application would not use >> them.  Dynamically linking is nice because problems in the library can be fixed >> and shipped without forcing the user recompile.  Though the user may not >> realize  it, this change forces them to recompile. >> >> Tom > Thanks Tom. In that very context, the change are big enough not to have any form of compatibility. This a new ABI version, and user knows they will have to recompile. > Still it would be great to capture a recommendation in DPDK coding guideline in case there is such a BKM, I have heard multiple arguments for different preference, if we want to harmonize such things let's capture in coding guide lines, it would not hurt. Maybe one for Thomas? When sw is deployed, how would a user know ? For that matter, how would a developer know without a deep reading of header files ? I am not asking for a compatibility testsuite here, just the placement of new elements (the same code) at the end of structures.  As a library writer, please consider the users of the library.  Your improvements are amplified by all of the library's users.  The user's code quality is based on this library's code quality. My expectation is a new ABI introduces new functionality without breaking old binaries. Or if it does, it is for a good reason. There is no good reason for putting new elements into the middle of an existing structure. Tom > >>>> Tom >>>> >>>>> /** Queue size limit (queue size must also be power of 2) */ >>>>> uint32_t queue_size_lim; >>>>> /** Set if device off-loads operation to hardware */