From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Felix Fietkau <nbd@nbd.name>, linux-wireless@vger.kernel.org
Cc: johannes@sipsolutions.net
Subject: Re: [PATCH 2/7] mac80211: force calculation of software hash for tx fair queueing
Date: Thu, 17 Dec 2020 18:26:06 +0100 [thread overview]
Message-ID: <874kkk9wep.fsf@toke.dk> (raw)
In-Reply-To: <07ad2533-b477-abf1-5176-0521ca9ddf82@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> 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.
But then we'd need to go around adding this to all the places that uses
the hash just to work around a particular piece of broken(ish) hardware.
And we're hard-coding a behaviour in mac80211 that means we'll *always*
recompute the hash, even for hardware that's not similarly broken.
> 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.
So wouldn't the right thing to do here be to put a flag into the RX
device that makes the stack clear the hash after using it for GRO?
-Toke
next prev parent reply other threads:[~2020-12-17 17:27 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-16 20:43 [PATCH 1/7] net/fq_impl: bulk-free packets from a flow on overmemory Felix Fietkau
2020-12-16 20:43 ` [PATCH 2/7] mac80211: force calculation of software hash for tx fair queueing Felix Fietkau
2020-12-17 11:54 ` Toke Høiland-Jørgensen
2020-12-17 12:20 ` Felix Fietkau
2020-12-17 13:01 ` Toke Høiland-Jørgensen
2020-12-17 15:48 ` Felix Fietkau
2020-12-17 17:26 ` Toke Høiland-Jørgensen [this message]
2020-12-17 19:07 ` Felix Fietkau
2020-12-18 12:41 ` Toke Høiland-Jørgensen
2020-12-18 13:40 ` Felix Fietkau
2020-12-18 15:49 ` Toke Høiland-Jørgensen
2020-12-16 20:43 ` [PATCH 3/7] net/fq_impl: drop get_default_func, move default flow to fq_tin Felix Fietkau
2020-12-17 11:55 ` Toke Høiland-Jørgensen
2020-12-16 20:43 ` [PATCH 4/7] net/fq_impl: do not maintain a backlog-sorted list of flows Felix Fietkau
2020-12-16 20:59 ` Johannes Berg
2020-12-17 12:40 ` Felix Fietkau
2020-12-16 20:43 ` [PATCH 5/7] mac80211: fix encryption key selection for 802.3 xmit Felix Fietkau
2020-12-16 20:43 ` [PATCH 6/7] mac80211: fix fast-rx encryption check Felix Fietkau
2020-12-16 20:43 ` [PATCH 7/7] mac80211: add rx decapsulation offload support Felix Fietkau
2020-12-16 21:03 ` Johannes Berg
2020-12-16 21:19 ` Felix Fietkau
2020-12-17 8:08 ` Johannes Berg
2020-12-16 21:04 ` Johannes Berg
2020-12-16 21:06 ` Felix Fietkau
2020-12-16 20:54 ` [PATCH 1/7] net/fq_impl: bulk-free packets from a flow on overmemory Johannes Berg
2020-12-16 21:28 ` Felix Fietkau
2020-12-17 12:09 ` Toke Høiland-Jørgensen
2020-12-17 11:51 ` Toke Høiland-Jørgensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874kkk9wep.fsf@toke.dk \
--to=toke@redhat.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@nbd.name \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.