Hi Stephen, On 05/31/2016 10:28 PM, Stephen Hemminger wrote: > On Tue, 31 May 2016 21:11:59 +0200 > Olivier MATZ <olivier.matz at 6wind.com> wrote: > >> >> >> On 05/31/2016 10:09 AM, Yuanhan Liu wrote: >>> On Mon, May 30, 2016 at 05:26:21PM +0200, Olivier Matz wrote: >>>> PKT_RX_L4_CKSUM_NONE: the L4 checksum is not correct in the packet >>>> data, but the integrity of the L4 header is verified. >>>> -> the application can process the packet but must not verify the >>>> checksum by sw. It has to take care to recalculate the cksum >>>> if the packet is transmitted (either by sw or using tx offload) >>> >>> I like the explanation you made at [1] better :) >>> >>> So in general, I think this proposal is good to have. >> >> Thanks everyone for your feedback. >> >> I'll try to send a first patch proposition soon. >> >> Regards, >> Olivier > > I think it is time to ditch the old definitions of Rx checksum and instead > use something more compatiable with virtio (and Linux). I.e have three values > 1) checksum is know good for packet contents > 2) checksum value one's complement for packet contents > 3) checksum is undetermined > The original definition seems to be Intel HW centric and applies to a limited > range of devices making it unusable by general application. > > Break the ABI, and ditch the old values (ok mark PKT_RX_L4_CKSUM_BAD as > __deprecated > and remove all usage). >
Don't you think knowing that a checksum is bad could be useful? In that case the application can drop/log the packet without any additional cpu cost. What do you mean by beeing unusable by general application? I think the "2)" also requires a csum_start + csum_offset in mbuf structure, right? Do you also suggest to drop IP checksum flags? Will it be possible to manage tunnel checksums? I think this would be a pretty big change. If there is no additional argument than beeing more compatible with virtio/linux, I'm wondering if it's worth breaking the API. Let's wait for other opinions. Thanks for your feedback. Olivier