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 8A8CAA054F; Tue, 16 Mar 2021 13:14:37 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 532004069F; Tue, 16 Mar 2021 13:14:37 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 357B74003D for ; Tue, 16 Mar 2021 13:14:36 +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) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id D33E27F4A0; Tue, 16 Mar 2021 15:14:35 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru D33E27F4A0 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1615896875; bh=xVqa75TUx5kI++FDnP/FCqfdgps06AEZCX1t2anRMRE=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Vcqc0FCa641Vdmyit9cJSj6clRfBy+EFdCehrP6p11VnyapJFww7uGEhbfbnWTDY/ 27aiOqG/ylImxRJ0POvbfhOkrNiX8Pc/S2maL9lPxYXFMrWI7cvBkXoyTywmFb/x5f +BrSs6DKolrn/DVMpIEMUA8gaAvSwQXnGpNqm3CA= To: Ferruh Yigit 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: Andrew Rybchenko Organization: OKTET Labs Message-ID: Date: Tue, 16 Mar 2021 15:14:35 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 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/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.