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