Re: [dpdk-dev] Potential regression introduced by commit b10231aed1edb9

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

On 12/30/2020 12:55 PM, Balazs Nemeth wrote:
> Hi, I already posted a patch that fixes the issue on my side here:
> http://mails.dpdk.org/archives/dev/2020-December/195206.html
> 
> Regards,
> Balazs
> 
> On Wed, 2020-12-30 at 12:51 +0000, Devendra Singh Rawat wrote:
>> Adding more people to comment/investigate here.
>>
>> Devendra, could it be that we don't consider subsequent calls of
>> promisc_enabled + allmulti_enable ?
>>
>> Devendra >> yes, I agree that as long as promiscuous mode is enabled
>> for a port, all traffic should be accepted even if allmulticast is
>> enabled latter. Commit b10231aed1edb9 shouldn't have changed that.
>> I will prepare a fix patch for this.
>>
>> On 18/12/2020 2:34 pm, Balazs Nemeth wrote:
>>> Hi,
>>>
>>> introduces a regression on my systems. I have a
>>> "QLogic Corp. FastLinQ QL41000 Series 10/25/40/50GbE Controller"
>>> which
>>> relies on the qede driver. Calling
>>> rte_eth_promiscuous_enable(portid)
>>> followed by rte_eth_allmulticast_enable(port_id) causes no packets
>>> to
>>> arrive from my generator. It's important to add that the generator
>>> doesn't specifically target the mac of the port. I presume that
>>> irrespective of dst mac, if a port is put into promiscuous mode,
>>> all
>>> packets should arrive and rte_eth_allmulticast_enable should not
>>> cause
>>> *less* packets to arrive. Am I missing something? It seems that
>>> b10231aed1edb9 inadvertently introduced either a bug or a pretty
>>> significant change in semantics (at least for qede)?
>>>
>>> Regards,
>>> Balazs
>>>
> 

Hi Balazs,

You can create Bugzilla issue as well, that helps to record and track the 
issues: https://bugs.dpdk.org/