Hi Heqing, Thanks for pointing out the Rx cksum test case. I was looking for usage of IXGBE_RXDADV_ERR_SHIFT and IXGBE_RXDADV_ERR_MASK without any result, therefore I assumed these 2 fields are not checked.
So it turns out that the implementation of Rx cksum is in routine rx_desc_error_to_pkt_flags of ixgbe_rxtx.c. (Correct me if I'm wrong). This routine, however, doesn't comply with the datasheet. See end of page 324 of 82599 datasheet: >>L4E (10) ? L4 integrity error is valid only when the L4I bit in the Status >>field is set. It is >>active if L4 processing fails (TCP checksum or UDP checksum or SCTP CRC). Also beginning of section 7.1.11 confirms that the error bits are valid when status bits (IPCS/L4CS) are turned on. To be compliant with datasheet, the driver must check respective status bits before checking error bits in receive descriptor. thx & rgds, -Qinglai On Tue, Oct 8, 2013 at 9:59 AM, Zhu, Heqing <heqing.zhu at intel.com> wrote: > Hi Qinglai, > >>> Besides, as you mentioned, the ixgbe driver doesn't leverage the hardware >>> receive checksum offloading at all. > > On the Rx side, ixgbe driver support the Rx checksum validation via hardware > offload. There is a simple example @ DPDK\app\test-pmd\csumonly.c to check > IPv4/L4 checksum error~ > > /* Update the L3/L4 checksum error packet count */ > rx_bad_ip_csum += (uint16_t) ((pkt_ol_flags & > PKT_RX_IP_CKSUM_BAD) != 0); > rx_bad_l4_csum += (uint16_t) ((pkt_ol_flags & > PKT_RX_L4_CKSUM_BAD) != 0); > > -----Original Message----- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of jigsaw > Sent: Saturday, October 05, 2013 3:11 AM > To: Venkatesan, Venky > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] Request for comments on ixgbe TSO support > > Hi Stephen, > > Thanks for showing a bigger picture. > > GSO is quite big implementation, that I think it won't be easily ported to > DPDK. The mbuf needs to be equipped with many fields from skb to be able to > deal with GSO. > Do you have the plan to port GSO to DPDK, or you would like to keep GSO in > scope of virtio? > > Regarding checksum flags, actually I was also thinking of extending ol_flags > but then I gave it up coz I was worried about the size of mbuf. > My current patch has to push some work to user, due to the fact that mbuf > delivers too few info (such as L2 and L3 protocol details). > > Besides, as you mentioned, the ixgbe driver doesn't leverage the hardware > receive checksum offloading at all. And if this is to be supported, the > checksum flag need further extension. > (On the other hand, TSO doesn't care about receive checksum offloading). > Again, do you have plans to extend cksum flags so that virio feels more > comfortable with DPDK? > > Hi Venky, > > I can either make the commit now as is, or wait till the cksum flags > extension is in place. If Stephen (or somebody else) has the plan for better > support for cksum offloading or GSO, it is perhaps better to implement TSO on > top of that. > > BTW, I have another small question. Current TSO patch offloads the TCP/IP > pseudo cksum work to user. Do you think DPDK could provide some utility > functions for TCP/IPv4/IPv6 pseudo cksum calculation and updating? > > thx & > rgds, > -Qinglai > > > On Fri, Oct 4, 2013 at 9:38 PM, Venkatesan, Venky <venky.venkatesan at > intel.com> wrote: >> Stephen, >> >> Agree on the checksum flag definition. I'm presuming that we should do this >> on the L3 and L4 checksums separately (that ol_flags field is another one >> that needs extension in the mbuf). >> >> Regards, >> -Venky >> >> >> -----Original Message----- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger >> Sent: Friday, October 04, 2013 11:23 AM >> To: jigsaw >> Cc: dev at dpdk.org >> Subject: Re: [dpdk-dev] [PATCH] Request for comments on ixgbe TSO >> support >> >> On Fri, 4 Oct 2013 20:54:31 +0300 >> jigsaw <jigsaw at gmail.com> wrote: >> >>> Hi Stephen, >>> >>> >>> >>This will work for local generated packets but overlapping existing field >>> >>won't work well for forwarding. >>> So adding a new mss field in mbuf could be the way out? or I >>> misunderstand something. >>> >>> >> What we want to be able to do is to take offload (jumbo) packets >>> >> in with from virtio >>> Sorry I don't understand why TSO is connected to virtio. Could you >>> give more details here? >>> Are you suggesting this TSO patch overlaps your work, or it should be >>> based on your work? >> >> I am working on a better virtio driver. Already have lots more features >> working, and doing better offload support is planned. >> >> TSO is a subset of the more generic segment offload (GSO) on Linux. >> With virtio is possible to receive GSO packets as well as send them. >> This feature is negotiated between guest and host. >> >> The idea is that between guests they can exchange jumbo (64K) packets even >> with a smaller MTU. This helps in many ways. One example is only a single >> route lookup is needed. >> >> Another issue is that the current DPDK model of offload flags for checksum >> is problematic. >> It matches what is available in Intel hardware and is not easily >> generalizable to other devices. >> >> Current DPDK flag is checksum bad. I would like to change it to >> checksum known good. Then drivers which dont' do checksum would leave >> it 0, but if receive checksum is known good set it to 1. Basically 1 >> means known good, and >> 0 means unknown (or bad). Higher level software can then do sw checksum if >> necessary.
