Re: [dpdk-dev] [PATCH v2 3/3] net/sfc: support multi-process

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 5/22/2017 1:07 PM, Andrew Rybchenko wrote:
> On 05/22/2017 02:29 PM, Ferruh Yigit wrote:
>> On 5/18/2017 3:00 PM, Andrew Rybchenko wrote:
>>> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
>>> Reviewed-by: Andy Moreton <amoreton@solarflare.com>
>> <...>
>>
>>>  Linux VFIO           = Y
>>> diff --git a/drivers/net/sfc/sfc.h b/drivers/net/sfc/sfc.h
>>> index 772a713..007ed24 100644
>>> --- a/drivers/net/sfc/sfc.h
>>> +++ b/drivers/net/sfc/sfc.h
>>> @@ -225,7 +225,18 @@ struct sfc_adapter {
>>>  	uint8_t				rss_key[SFC_RSS_KEY_SIZE];
>>>  #endif
>>>  
>>> +	/*
>>> +	 * Shared memory copy of the Rx datapath name to be used by
>>> +	 * the secondary process to find Rx datapath to be used.
>>> +	 */
>>> +	char				*dp_rx_name;
>> Why not use sa->dp_rx->dp.name to find the dp_rx? That variable should
>> be shared between processes already?
> 
> sa->dp_rx is a pointer to .data section (sfc_efx_rx or sfc_ef10_rx)
> which is (may be) different in primary and secondary processes.

OK, thanks.
Does it make sense to implement strdup as rte_strdup, so others can
re-use it? @sergio, what do you think?

> 
>> <...>
>>
>>> diff --git a/drivers/net/sfc/sfc_ef10_rx.c b/drivers/net/sfc/sfc_ef10_rx.c
>>> index 1484bab..60812cb 100644
>>> --- a/drivers/net/sfc/sfc_ef10_rx.c
>>> +++ b/drivers/net/sfc/sfc_ef10_rx.c
>>> @@ -699,7 +699,7 @@ struct sfc_dp_rx sfc_ef10_rx = {
>>>  		.type		= SFC_DP_RX,
>>>  		.hw_fw_caps	= SFC_DP_HW_FW_CAP_EF10,
>>>  	},
>>> -	.features		= 0,
>>> +	.features		= SFC_DP_RX_FEAT_MULTI_PROCESS,
>> Why this flag is needed, I mean why multi process support is not always
>> enabled by default?
> 
> libefx-based datapath intensively uses function pointers (primary
> process function pointers stored in data structures). So, it does not
> work in multi process.

But this currently added always, if I don't miss anything. And only
checked once in secondary path and error returned if not set.

Is there any code path that behaves different based on this flag? Or any
case that this flags shouldn't be set?

What happens if this flag removed, and assumed it is always set? (this
and tx version of this flag)

> 
>> <...>
> 
>