[PATCH v2 7/8] net/ring: add promisc and all-MC stubs

[Ferruh Yigit]

On 2/4/2022 2:49 PM, Bruce Richardson wrote:
> On Fri, Feb 04, 2022 at 02:36:47PM +0000, Ferruh Yigit wrote:
>> On 12/21/2021 7:57 PM, Robert Sanford wrote:
>>> Add promiscuous_enable, promiscuous_disable, allmulticast_enable,
>>> and allmulticast_disable API stubs.
>>> This helps clean up errors in dpdk-test link_bonding_mode4_autotest.
>>>
>>> Signed-off-by: Robert Sanford <rsanford at akamai.com>
>>> ---
>>>    drivers/net/ring/rte_eth_ring.c | 28 ++++++++++++++++++++++++++++
>>>    1 file changed, 28 insertions(+)
>>>
>>> diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
>>> index db10f03..cfb81da 100644
>>> --- a/drivers/net/ring/rte_eth_ring.c
>>> +++ b/drivers/net/ring/rte_eth_ring.c
>>> @@ -226,6 +226,30 @@ eth_mac_addr_add(struct rte_eth_dev *dev __rte_unused,
>>>    }
>>>    static int
>>> +eth_promiscuous_enable(struct rte_eth_dev *dev __rte_unused)
>>> +{
>>> +	return 0;
>>> +}
>>> +
>>> +static int
>>> +eth_promiscuous_disable(struct rte_eth_dev *dev __rte_unused)
>>> +{
>>> +	return 0;
>>> +}
>>> +
>>> +static int
>>> +eth_allmulticast_enable(struct rte_eth_dev *dev __rte_unused)
>>> +{
>>> +	return 0;
>>> +}
>>> +
>>> +static int
>>> +eth_allmulticast_disable(struct rte_eth_dev *dev __rte_unused)
>>> +{
>>> +	return 0;
>>> +}
>>> +
>>> +static int
>>>    eth_link_update(struct rte_eth_dev *dev __rte_unused,
>>>    		int wait_to_complete __rte_unused) { return 0; }
>>> @@ -275,6 +299,10 @@ static const struct eth_dev_ops ops = {
>>>    	.stats_reset = eth_stats_reset,
>>>    	.mac_addr_remove = eth_mac_addr_remove,
>>>    	.mac_addr_add = eth_mac_addr_add,
>>> +	.promiscuous_enable = eth_promiscuous_enable,
>>> +	.promiscuous_disable = eth_promiscuous_disable,
>>> +	.allmulticast_enable = eth_allmulticast_enable,
>>> +	.allmulticast_disable = eth_allmulticast_disable,
>>
>> not sure about adding dummy dev_ops to the driver for the unit test,
>> what about updating 'link_bonding_mode4_autotest' accordingly?
>>
>> Bruce (net/ring maintainer), what do you think about dummy dev_ops?
> 
> For something like ring PMD, I don't see an issue with it, since they don't
> really have any meaning for a ring PMD, they might as well just return
> success rather than having application code have to handle errors from
> them.
> 
> 
> Acked-by: Bruce Richardson <bruce.richardson at intel.com>

Applied to dpdk-next-net/main, thanks.