[dpdk-users] Is it possible to receive packets with bad CRC?

[dpdk-users] Is it possible to receive packets with bad CRC?

[Ido Goshen]

Hi

By default bad CRC packets are dropped and raise the ierror counter.

Is there a way to change this behavior for I350 (igb) and rx it by the app?

I’ve tried setting DEV_RX_OFFLOAD_KEEP_CRC but this doesn’t help (I think this only keeps CRC for good packets)
I’ve also tried enabling the Store Bad Packet (not sure what it does but it’s the closet I could find) by setting in e1000/igb_rxtx.c
rctl |= E1000_RCTL_SBP;  E1000_WRITE_REG(hw, E1000_RCTL, rctl);
Didn’t help either.

Is it possible to do with I350?
Or with any of the other intel NICs? X522 (ixgbe) or X710 (i40e)?

Thanx,

  *   Ido

Re: [dpdk-users] Is it possible to receive packets with bad CRC?

[JieSong]

Hi Ido,
    I have the same question as yours, I want to get all the packets even the CRC/FCS error packet.
    Without DPDK I set the nic with "ethtool -K rx-all on", Then i can tcpdump all the packets both good and error packets.
    But I have no ideal with DPDK. Did you find something for this question? 


Thanks


Jie



 
 
 
------------------ Original ------------------
From: &nbsp;"Ido Goshen"<Ido@cgstowernetworks.com&gt;;
Date: &nbsp;Mon, Dec 14, 2020 00:56 AM
To: &nbsp;"users@dpdk.org"<users@dpdk.org&gt;; 

Subject: &nbsp;[dpdk-users] Is it possible to receive packets with bad CRC?

&nbsp;

Hi

By default bad CRC packets are dropped and raise the ierror counter.

Is there a way to change this behavior for I350 (igb) and rx it by the app?

I’ve tried setting DEV_RX_OFFLOAD_KEEP_CRC but this doesn’t help (I think this only keeps CRC for good packets)
I’ve also tried enabling the Store Bad Packet (not sure what it does but it’s the closet I could find) by setting in e1000/igb_rxtx.c
rctl |= E1000_RCTL_SBP;&nbsp; E1000_WRITE_REG(hw, E1000_RCTL, rctl);
Didn’t help either.

Is it possible to do with I350?
Or with any of the other intel NICs? X522 (ixgbe) or X710 (i40e)?

Thanx,

&nbsp; *&nbsp;&nbsp; Ido

Re: [dpdk-users] Is it possible to receive packets with bad CRC?

[Stephen Hemminger]

On Tue, 8 Jun 2021 11:44:10 +0800
"JieSong" <songj@zctt.com> wrote:

> Hi Ido,
> &nbsp; &nbsp; I have the same question as yours, I want to get all the packets even the CRC/FCS error packet.
> &nbsp; &nbsp; Without DPDK I set the nic with "ethtool -K rx-all on", Then i can tcpdump all the packets both good and error packets.
> &nbsp; &nbsp; But I have no ideal with DPDK. Did you find something for this question?&nbsp;
> 
> 
> Thanks
> 
> 
> Jie
> 
> 
> 
> &nbsp;
> &nbsp;
> &nbsp;
> ------------------&nbsp;Original&nbsp;------------------
> From: &nbsp;"Ido Goshen"<Ido@cgstowernetworks.com&gt;;
> Date: &nbsp;Mon, Dec 14, 2020 00:56 AM
> To: &nbsp;"users@dpdk.org"<users@dpdk.org&gt;; 
> 
> Subject: &nbsp;[dpdk-users] Is it possible to receive packets with bad CRC?
> 
> &nbsp;
> 
> Hi
> 
> By default bad CRC packets are dropped and raise the ierror counter.
> 
> Is there a way to change this behavior for I350 (igb) and rx it by the app?
> 
> I’ve tried setting DEV_RX_OFFLOAD_KEEP_CRC but this doesn’t help (I think this only keeps CRC for good packets)
> I’ve also tried enabling the Store Bad Packet (not sure what it does but it’s the closet I could find) by setting in e1000/igb_rxtx.c
> rctl |= E1000_RCTL_SBP;&nbsp; E1000_WRITE_REG(hw, E1000_RCTL, rctl);
> Didn’t help either.
> 
> Is it possible to do with I350?
> Or with any of the other intel NICs? X522 (ixgbe) or X710 (i40e)?
> 
> Thanx,
> 
> &nbsp; *&nbsp;&nbsp; Ido


Please don't use HTML mail on the DPDK mailing list.

The DPDK ethdev API does not have a way to enable storing bad packets.
The DPDK ixgbe driver has a device specific API call rte_pmd_ixgbe_udp_fctrl_sbp which may
do what you want.  Device specific API's are discouraged but possible.

Re: [dpdk-users] Is it possible to receive packets with bad CRC?

[songj]

Hi Stephen

Thank you very much, you point out the correct function rte_pmd_ixgbe_udp_fctrl_sbp that I want.

I do a quick test about if DPDK can receive error packet:  
1.  With the original DPDK testpmd just show the number of error packets in RX-errors,  but not RX-packets.
2.  I modify fucntion  ixgbe_dev_rx_init with adding IXGBE_FCTRL_SBP for the eth device,  Testpmd will show the number of error packets both in RX-errors and  RX-packets，so the eth device can receive error packets in DPDK now.


Thanks

Jie
  



 



> Hi Ido,



>     I have the same question as yours, I want to get all the packets even the CRC/FCS error packet.



>     Without DPDK I set the nic with "ethtool -K rx-all on", Then i can tcpdump all the packets both good and error packets.



>     But I have no ideal with DPDK. Did you find something for this question? 



>



>



> Thanks



>



>



> Jie



>



>



>



>  



>  



>  



> ------------------ Original ------------------



> From: &nbsp;"Ido Goshen"<Ido@cgstowernetworks.com&gt;;



> Date: &nbsp;Mon, Dec 14, 2020 00:56 AM



> To: &nbsp;"users@dpdk.org"<users@dpdk.org&gt;;



>



> Subject: &nbsp;[dpdk-users] Is it possible to receive packets with bad CRC?



>



> &nbsp;



>



> Hi



>



> By default bad CRC packets are dropped and raise the ierror counter.



>



> Is there a way to change this behavior for I350 (igb) and rx it by the app?



>



> I’ve tried setting DEV_RX_OFFLOAD_KEEP_CRC but this doesn’t help (I think this only keeps CRC for good packets)



> I’ve also tried enabling the Store Bad Packet (not sure what it does but it’s the closet I could find) by setting in e1000/igb_rxtx.c



> rctl |= E1000_RCTL_SBP;&nbsp; E1000_WRITE_REG(hw, E1000_RCTL, rctl);



> Didn’t help either.



>



> Is it possible to do with I350?



> Or with any of the other intel NICs? X522 (ixgbe) or X710 (i40e)?



>



> Thanx,



>



> &nbsp; *&nbsp;&nbsp; Ido



 



 



Please don't use HTML mail on the DPDK mailing list.



 



The DPDK ethdev API does not have a way to enable storing bad packets.



The DPDK ixgbe driver has a device specific API call rte_pmd_ixgbe_udp_fctrl_sbp which may



do what you want.  Device specific API's are discouraged but possible.