Re: [dpdk-dev] [PATCH v4 1/8] common/sfc_efx/base: add base virtio support for vDPA

[Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>]

On 3/16/21 2:30 PM, Ferruh Yigit wrote:
> On 3/16/2021 8:58 AM, Andrew Rybchenko wrote:
>> From: Vijay Srivastava <vijays@solarflare.com>
>>
>> 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 <vijays@solarflare.com>
>> Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> 
> <...>
> 
>> 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.