From: Alexander Lobakin <alexandr.lobakin@intel.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>,
bpf@vger.kernel.org, xdp-hints@xdp-project.net,
martin.lau@kernel.org, daniel@iogearbox.net,
netdev@vger.kernel.org, ast@kernel.org,
Stanislav Fomichev <sdf@google.com>,
yoong.siang.song@intel.com, anthony.l.nguyen@intel.com,
intel-wired-lan@lists.osuosl.org
Subject: [xdp-hints] Re: [Intel-wired-lan] [PATCH bpf-next V1] igc: enable and fix RX hash usage by netstack
Date: Tue, 14 Feb 2023 16:13:03 +0100 [thread overview]
Message-ID: <b6143e67-a0f1-a238-f901-448b85281154@intel.com> (raw)
In-Reply-To: <6a5ded96-2425-ff9b-c1b1-eca1c103164c@molgen.mpg.de>
From: Paul Menzel <pmenzel@molgen.mpg.de>
Date: Tue, 14 Feb 2023 16:00:52 +0100
> Dear Jesper,
>
>
> Thank you very much for your patch.
>
> Am 10.02.23 um 16:07 schrieb Jesper Dangaard Brouer:
>> When function igc_rx_hash() was introduced in v4.20 via commit
>> 0507ef8a0372
>> ("igc: Add transmit and receive fastpath and interrupt handlers"), the
>> hardware wasn't configured to provide RSS hash, thus it made sense to not
>> enable net_device NETIF_F_RXHASH feature bit.
>>
>> The NIC hardware was configured to enable RSS hash info in v5.2 via
>> commit
>> 2121c2712f82 ("igc: Add multiple receive queues control supporting"), but
>> forgot to set the NETIF_F_RXHASH feature bit.
>>
>> The original implementation of igc_rx_hash() didn't extract the
>> associated
>> pkt_hash_type, but statically set PKT_HASH_TYPE_L3. The largest
>> portions of
>> this patch are about extracting the RSS Type from the hardware and
>> mapping
>> this to enum pkt_hash_types. This were based on Foxville i225 software
>> user
>
> s/This were/This was/
>
>> manual rev-1.3.1 and tested on Intel Ethernet Controller I225-LM (rev
>> 03).
>>
>> For UDP it's worth noting that RSS (type) hashing have been disabled
>> both for
>> IPv4 and IPv6 (see IGC_MRQC_RSS_FIELD_IPV4_UDP +
>> IGC_MRQC_RSS_FIELD_IPV6_UDP)
>> because hardware RSS doesn't handle fragmented pkts well when enabled
>> (can
>> cause out-of-order). This result in PKT_HASH_TYPE_L3 for UDP packets, and
>
> result*s*
>
>> hash value doesn't include UDP port numbers. Not being
>> PKT_HASH_TYPE_L4, have
>> the effect that netstack will do a software based hash calc calling into
>> flow_dissect, but only when code calls skb_get_hash(), which doesn't
>> necessary happen for local delivery.
>
> Excuse my ignorance, but is that bug visible in practice by users
> (performance?) or is that fix needed for future work?
Hash calculation always happens when RPS or RFS is enabled. So having no
hash in skb before hitting the netstack slows down their performance.
Also, no hash in skb passed from the driver results in worse NAPI bucket
distribution when there are more traffic flows than Rx queues / CPUs.
+ Netfilter needs hashes on some configurations.
On default configurations and workloads like browsing the Internet this
usually is not the case, but only then I'd say.
>
>> Fixes: 2121c2712f82 ("igc: Add multiple receive queues control
>> supporting")
>> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
[...]
Nice to see that you also care about (not) using short types on the stack :)
> Kind regards,
>
> Paul
>
>
> [1]: https://notabs.org/coding/smallIntsBigPenalty.htm
Thanks,
Olek
next prev parent reply other threads:[~2023-02-14 15:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 15:07 [xdp-hints] " Jesper Dangaard Brouer
2023-02-10 15:23 ` [xdp-hints] " Jesper Dangaard Brouer
2023-02-14 13:21 ` Alexander Lobakin
2023-02-16 16:46 ` Jesper Dangaard Brouer
2023-02-20 15:39 ` Alexander Lobakin
2023-02-22 15:00 ` Jesper Dangaard Brouer
2023-02-24 16:41 ` Alexander Lobakin
2023-02-27 14:24 ` Alexander Lobakin
2023-02-14 15:00 ` [xdp-hints] Re: [Intel-wired-lan] " Paul Menzel
2023-02-14 15:13 ` Alexander Lobakin [this message]
2023-02-16 15:17 ` Jesper Dangaard Brouer
2023-02-16 15:43 ` Alexander Lobakin
2023-02-27 14:53 ` Alexander Lobakin
2023-02-16 13:29 ` Jesper Dangaard Brouer
2023-02-16 15:34 ` Alexander Lobakin
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
List information: https://lists.xdp-project.net/postorius/lists/xdp-hints.xdp-project.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b6143e67-a0f1-a238-f901-448b85281154@intel.com \
--to=alexandr.lobakin@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=martin.lau@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pmenzel@molgen.mpg.de \
--cc=sdf@google.com \
--cc=xdp-hints@xdp-project.net \
--cc=yoong.siang.song@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox