[dpdk-dev] Potential regression introduced by commit b10231aed1edb9

[dpdk-dev] Potential regression introduced by commit b10231aed1edb9

[Balazs Nemeth]

Hi,

Commit b10231aed1edb9 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

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

[Igor Russkikh]

Hi Balazs,

This could be a regression for your specific usecase.

The commit itself tried to fix promisc as is.

Adding more people to comment/investigate here.

Devendra, could it be that we don't consider subsequent calls of
promisc_enabled + allmulti_enable ?

On 18/12/2020 2:34 pm, Balazs Nemeth wrote:
> Hi,
> 
> Commit b10231aed1edb9 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
> 

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

[Devendra Singh Rawat]

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
> 

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

[Balazs Nemeth]

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
> > 

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

[Ferruh Yigit]

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/