[dpdk-dev] [PATCH v3 08/13] testpmd: rework csum forward engine
olivier.matz at 6wind.com
Wed Nov 26 12:14:42 CET 2014
On 11/26/2014 11:10 AM, Ananyev, Konstantin wrote:
> As I can see you removed code that sets up TX_PKT_IPV4 and TX_PKT_IPV6 of ol_flags.
> I think that we need to keep it.
> The reason for that is:
> With FVL, to make HW TX checksum offload work, SW is responsible to provide to the HW information about L3 header.
> Possible values are:
> - IPv4 hdr with HW checksum calculation
> - IPV4 hdr (checksum done by SW)
> - IPV6 hdr
> - unknown
> So let say to for the packet: ETHER_HDR/IPV6_HDR/TCP_HDR/DATA
> To request HW TCP checksum offload, SW have to provide to HW information that it is a packet with IPV6 header
> (plus as for ixgbe: l2_hdr_len, l3_hdr_len, l4_type, l4_hdr_len).
> That's why TX_PKT_IPV4 and TX_PKT_IPV6 were introduced.
> Yes, it is a change in public API for HW TX offload, but I don't see any other way we can overcome it
> (apart from make TX function itself to parse a packet, which is obviously not a good choice).
> Note that existing apps working on existing HW (ixgbe/igb/em) are not affected.
> Though apps that supposed to be run on FVL HW too have to follow new convention.
> So I suggest we keep setting these flags in csumonly.c
Right, I missed these flags.
It's indeed an API change, but maybe it makes sense, and setting it
is not a big cost for the application.
So I would also need to slightly modify the API help in the following
- [04/13] mbuf: add help about TX checksum flags
- [10/13] mbuf: generic support for TCP segmentation offload
I'll send a v4 this afternoon that integrates this change.
Do you know precisely when the flags PKT_TX_IPV4 and PKT_TX_IPV6 must
be set by the application? Is it only the hw checksum and tso use case?
If yes, I'll add it in the API help too.
By the way (this is probably off-topic), but I'm wondering if the TX
flags should have the same values than the RX flags:
#define PKT_TX_IPV4 PKT_RX_IPV4_HDR
#define PKT_TX_IPV6 PKT_RX_IPV6_HDR
> Apart from that , the patch looks good to me.
> And yes, we would need to change the the way we handle TX offload for tunnelled packets.
Thank you very much Konstantin for your review.
More information about the dev