DPDK usage discussions
 help / color / mirror / Atom feed
From: "songj@zctt.com" <songj@zctt.com>
To: stephen <stephen@networkplumber.org>
Cc: "Ido Goshen" <Ido@cgstowernetworks.com>,  users <users@dpdk.org>
Subject: Re: [dpdk-users] Is it possible to receive packets with bad CRC?
Date: Wed, 9 Jun 2021 12:58:52 +0800	[thread overview]
Message-ID: <2021060912584016728766@zctt.com> (raw)
In-Reply-To: <20210608082326.66e83722@hermes.local>

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,



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



 



      reply	other threads:[~2021-06-09  4:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-13 16:55 Ido Goshen
2021-06-08  3:44 ` JieSong
2021-06-08 15:23   ` Stephen Hemminger
2021-06-09  4:58     ` songj [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2021060912584016728766@zctt.com \
    --to=songj@zctt.com \
    --cc=Ido@cgstowernetworks.com \
    --cc=stephen@networkplumber.org \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).