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 C61ACA054F; Tue, 16 Mar 2021 13:42:15 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1EE8D242901; Tue, 16 Mar 2021 13:42:11 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id 15AC82428EF for ; Tue, 16 Mar 2021 13:42:08 +0100 (CET) IronPort-SDR: f2ZOLJvtctQtut28evjY1PC4TK0ZLX7GgelJqXPeYz2KEW9N+sIRtw1RbNrkMurrAXDH3Obnnt ANyp4483EA8g== X-IronPort-AV: E=McAfee;i="6000,8403,9924"; a="185889220" X-IronPort-AV: E=Sophos;i="5.81,251,1610438400"; d="scan'208";a="185889220" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Mar 2021 05:41:58 -0700 IronPort-SDR: CkBHBRo0D4+NVoqAYoET33/8Dm1lnVlsWWe8slBuVNw74E7iiOb8RXTjXnLwPgQjxVoAqxYpqz 8e2BzndU2YMQ== X-IronPort-AV: E=Sophos;i="5.81,251,1610438400"; d="scan'208";a="405531839" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.11.157]) ([10.252.11.157]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Mar 2021 05:41:57 -0700 To: Andrew Rybchenko Cc: dev@dpdk.org, Vijay Srivastava References: <20210311110325.3291203-1-andrew.rybchenko@oktetlabs.ru> <20210316085832.942481-1-andrew.rybchenko@oktetlabs.ru> <20210316085832.942481-2-andrew.rybchenko@oktetlabs.ru> <7fc1d368-ed21-1c4d-e006-a679cba5b0a4@oktetlabs.ru> From: Ferruh Yigit X-User: ferruhy Message-ID: <2750d1ea-98f5-dcd4-b85b-25db8192c598@intel.com> Date: Tue, 16 Mar 2021 12:41:56 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v4 1/8] common/sfc_efx/base: add base virtio support for vDPA 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 Sender: "dev" On 3/16/2021 12:14 PM, Andrew Rybchenko wrote: > On 3/16/21 2:58 PM, Ferruh Yigit wrote: >> On 3/16/2021 11:47 AM, Andrew Rybchenko wrote: >>> On 3/16/21 2:30 PM, Ferruh Yigit wrote: >>>> On 3/16/2021 8:58 AM, Andrew Rybchenko wrote: >>>>> From: Vijay Srivastava >>>>> >>>>> In the vDPA mode, only data path is offloaded in the hardware and >>>>> control path still goes through the hypervisor and it configures >>>>> virtqueues via vDPA driver so new virtqueue APIs are required. >>>>> >>>>> Implement virtio init/fini and virtqueue create/destroy APIs. >>>>> >>>>> Signed-off-by: Vijay Srivastava >>>>> Signed-off-by: Andrew Rybchenko >>>> >>>> <...> >>>> >>>>> diff --git a/drivers/common/sfc_efx/efsys.h >>>>> b/drivers/common/sfc_efx/efsys.h >>>>> index 663601412e..d133d61b3d 100644 >>>>> --- a/drivers/common/sfc_efx/efsys.h >>>>> +++ b/drivers/common/sfc_efx/efsys.h >>>>> @@ -187,6 +187,8 @@ prefetch_read_once(const volatile void *addr) >>>>>      #define EFSYS_OPT_MAE 1 >>>>>    +#define EFSYS_OPT_VIRTIO 0 >>>>> + >>>> >>>> Hi Andrew, >>>> >>>> How this 'efsys.h' works, is it compile time configuration file for the >>>> driver? >>> >>> Yes, it is a compile time configuration of the base driver. >>> >>>> Is is expected that users change this file? >>> >>> Client drivers (e.g. net/sfc or vdpa/sfc) change the base >>> driver configuration when it needs corresponding functionality >>> from the base driver. Of course, it is not ideal to add code >>> which is not actually compiled right now, but we always try >>> to ensure that build finally works fine and no extra patches >>> will be required to fix the build when corresponding option >>> is enabled. >>> >>> In theory we can send longer patch series which includes >>> the vdpa/sfc driver, but it will be longer patch series which >>> is harder to chew. >>> >> >> It is OK to send preparation sets first, that wasn't my point. > > I see. > >> My concern is having compile time configuration within driver, my >> question is if end user of the driver need to tweak these config >> options, if so should it be more generic way instead of a PMD specific >> way... > > No, it is not a user configuration. It is configuration done by > client (net/sfc, vdpa/sfc) drivers which use the common driver. > OK, thanks for clarification.