Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= <toke@redhat.com>,
        linux-wireless@vger.kernel.org
Cc:     johannes@sipsolutions.net
References: <20201216204316.44498-1-nbd@nbd.name>
 <20201216204316.44498-2-nbd@nbd.name> <87czz8bqbj.fsf@toke.dk>
 <add3d1fa-c2ad-5aaf-83c7-31e919129bbf@nbd.name> <871rfobn8w.fsf@toke.dk>
From:   Felix Fietkau <nbd@nbd.name>
Subject: Re: [PATCH 2/7] mac80211: force calculation of software hash for tx
 fair queueing
Message-ID: <07ad2533-b477-abf1-5176-0521ca9ddf82@nbd.name>
Date:   Thu, 17 Dec 2020 16:48:15 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
 Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <871rfobn8w.fsf@toke.dk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 2020-12-17 14:01, Toke Høiland-Jørgensen wrote:
> Felix Fietkau <nbd@nbd.name> writes:
> 
>> On 2020-12-17 12:54, Toke Høiland-Jørgensen wrote:
>>> Felix Fietkau <nbd@nbd.name> writes:
>>> 
>>>> Depending on the source, a hardware calculated hash may not provide the
>>>> same level of collision resistance.
>>> 
>>> This seems like it would have performance implications?
>>> 
>>> Also, this can potentially discard information from tunnels that
>>> preserve the hash before encapsulation (we added support for this to
>>> Wireguard which had some nice effects on queueing of encapsulated
>>> traffic).
>> If the hash was calculated in software using the flow dissector, it will
>> be preserved, even if it went through a few virtual interfaces.
>> The only hashes discarded are hardware generated ones.
> 
> Yeah, but I was thinking something like:
> 
> Packet comes in with HW hash -> gets encapsulated (preserving the hash)
> -> gets to mac80211 which discards the HW hash. So now you're replacing
> a (possibly bad-quality) HW hash with a software hash of the *outer*
> encapsulation header...
If this becomes a problem, I think we should add a similar patch to
wireguard, which already calls skb_get_hash before encapsulating.
Other regular tunnels should already get a proper hash, since the flow
dissector will take care of it.

The reason I did this patch is because I have a patch to set the hw flow
hash in the skb on mtk_eth_soc, which does help GRO, but leads to
collisions on mac80211 fq.

- Felix