Re: [PATCH net-next v2 0/3] net: device features handling fixes

[David Miller <davem@davemloft.net>]

From: Michal Kubecek <mkubecek@suse.cz>
Date: Tue, 20 May 2014 08:29:15 +0200 (CEST)

>> I think we need to think more about what exact behavior is desired in
>> mixed csum feature set cases.  Probably whatever csum offload type is
>> the most prevelant should be the one advertised by the master.  It
>> means we will do that software checksum fixup for the oddball slaves,
>> but it seems the best we can do.
> 
> I've been thinking about it some more and I believe what I proposed is
> correct: features that are or-ed (ONE_FOR_ALL) should start with 0,
> those which are and-ed (ALL_FOR_ALL) with 1.
> 
> But once we do that, we have to fix another problem in vlan module:
> features of a vlan device are mostly computed as bitwise AND of features
> and vlan_features of its underlying device. The problem is checksumming
> features don't really behave like independent flags as their main
> purpose is to be used in can_checksum_protocol() whose logic is that
> HW_CSUM (GEN_CSUM) means "can checksum everything" so that it kind of
> contains IP(V6)_CSUM functionality. Therefore intersection of HW_CSUM
> and IP(V6)_CSUM should result in the latter.
> 
> An alternative approach would be to always set IP(V6)_CSUM once HW_CSUM
> (any of GEN_CSUM) is set but as for long time people were taught not to
> do that and we even have a warning for it, switching to the exact
> opposite could cause a lot of problems.

Ok, looks good, series applied to net-next, thanks.