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 86607A0032; Wed, 13 Jul 2022 15:26:49 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 27FE14282D; Wed, 13 Jul 2022 15:26:49 +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 153A34280D for ; Wed, 13 Jul 2022 15:26:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1657718807; 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: in-reply-to:in-reply-to:references:references; bh=Hq/gLXbIGkFTzHqkOrrHmwCW+MO0l0XIX2TviROJAo0=; b=UHn/w9OMXDz23tcwiD9wq/P6+nXmRy4UVEYTbhRKJJ/yDdMUgSFWkie4ve5+UHauQyTEBU NwPv88VcL42WvgeXqwqWWAJ7yCznoGAZYeuIFFsImoaYgmB0VWYC2FAp7GCd5XxzK5cgJ0 mubkdVGyOAS65s0K268D6OHde+v/Vt0= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-170-My2LxoIIMXyZ57eWy_BK7g-1; Wed, 13 Jul 2022 09:26:46 -0400 X-MC-Unique: My2LxoIIMXyZ57eWy_BK7g-1 Received: by mail-lf1-f72.google.com with SMTP id k25-20020a195619000000b00489e6a6527eso3373539lfb.8 for ; Wed, 13 Jul 2022 06:26:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Hq/gLXbIGkFTzHqkOrrHmwCW+MO0l0XIX2TviROJAo0=; b=nOaxeLWExAASbAiPeZ+y5F39NcIGsw7QeNMkNNVUz9JxTJDty4Y1wm1TDo3Og/yETc +BXro1RQR7Az5KCgObUq+/qT0Jg0DZp3rofWlBVyVNHlWTSaD6Oh3sOEIT8Wh4+O7Wrh 4cqbimhHqwEpXt71p0Oa9iITCs3hlHXg0ufnux44YJKGUAemkmSYQYlRxKR3Fkx0wLsp RSxB9hXBCl/gtcnmfBagNotpwBYEyI3y6Ds2ApnJsPD0vVoBWuLnw2b1a3IZxQo2+N3v fWiK953pD0zggEhPNjxls/qjkF8ZD91CfcW8L76fzwFj+COVdRydi95CCcI77v88xD7G xPBA== X-Gm-Message-State: AJIora8MQNlb+nNeb7v0OkrHuLUZ6w8xQoJX6+7Vl8Hp8yHr1iJn6SWQ CyNQ9EfartG3En+S575eqvC2gItYG2zIDRlQtzmxVEmM/OP9IWxwO0rBI4LixLXs+hZdwhH9tSb +HKXyr5Dp7IptgkeaTZI= X-Received: by 2002:a05:6512:280d:b0:489:d766:5e3 with SMTP id cf13-20020a056512280d00b00489d76605e3mr2016119lfb.499.1657718804812; Wed, 13 Jul 2022 06:26:44 -0700 (PDT) X-Google-Smtp-Source: AGRyM1shTPKvOQAabBA1O05m4MyJiIxoNdWygADCSXTtWptn2cADr8JlvilbQMXvsnoHUCv7WJQxML8YPXrsU9CmBdE= X-Received: by 2002:a05:6512:280d:b0:489:d766:5e3 with SMTP id cf13-20020a056512280d00b00489d76605e3mr2016108lfb.499.1657718804598; Wed, 13 Jul 2022 06:26:44 -0700 (PDT) MIME-Version: 1.0 References: <20210518073441.2749096-1-thomas@monjalon.net> <20220712133610.4175033-1-thomas@monjalon.net> In-Reply-To: <20220712133610.4175033-1-thomas@monjalon.net> From: David Marchand Date: Wed, 13 Jul 2022 15:26:33 +0200 Message-ID: Subject: Re: [PATCH v2] doc: announce transition to vDPA device name function To: Thomas Monjalon Cc: dev , Andrew Rybchenko , Maxime Coquelin , "Xia, Chenbo" , Ray Kinsella , Xiao Wang , Matan Azrad , Vijay Kumar Srivastava , Ferruh Yigit Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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 Tue, Jul 12, 2022 at 3:36 PM Thomas Monjalon wrote: > > There is a layer violation in the vDPA API for getting the device name. > Instead of providing the name at vDPA level, > a function returns the low-level device object. Exposing a rte_device (as an opaque pointer) in upper device classes seems a good thing to me. With the API rework I proposed, we will have accessors to get this object characteristics (like here, a name identifying it). Having the vDPA API returns a pointer to a rte_device object makes it possible to reuse those accessors, nothing more needed. If the rte_device object is extended in any (unforeseen at the moment) way in the future, it would still be a matter of using the relevant accessor. No update needed in the vDPA API at this point in the future. On the other hand, what you propose here seems to go the other way. With each device classes needing to expose, through its own means / API, the underlying rte_device characteristics. -- David Marchand