From: Jarod Wilson <jarod@redhat.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: linux-kernel@vger.kernel.org, Jay Vosburgh <j.vosburgh@gmail.com>,
Veaceslav Falico <vfalico@gmail.com>,
Andy Gospodarek <andy@greyhouse.net>,
"David S. Miller" <davem@davemloft.net>,
Thomas Davis <tadavis@lbl.gov>,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next v2] bonding: add a vlan+mac tx hashing option
Date: Thu, 14 Jan 2021 16:42:03 -0500 [thread overview]
Message-ID: <20210114214203.GI1171031@redhat.com> (raw)
In-Reply-To: <20210114132314.2c484e9f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On Thu, Jan 14, 2021 at 01:23:14PM -0800, Jakub Kicinski wrote:
> On Thu, 14 Jan 2021 16:11:41 -0500 Jarod Wilson wrote:
> > In truth, this code started out as a copy of bond_eth_hash(), which also
> > only uses the last byte, though of both source and destination macs. In
> > the typical use case for the requesting user, the bond is formed from two
> > onboard NICs, which typically have adjacent mac addresses, i.e.,
> > AA:BB:CC:DD:EE:01 and AA:BB:CC:DD:EE:02, so only the last byte is really
> > relevant to hash differently, but in thinking about it, a replacement NIC
> > because an onboard one died could have the same last byte, and maybe we
> > ought to just go full source mac right off the go here.
> >
> > Something like this instead maybe:
> >
> > static u32 bond_vlan_srcmac_hash(struct sk_buff *skb)
> > {
> > struct ethhdr *mac_hdr = (struct ethhdr *)skb_mac_header(skb);
> > u32 srcmac = 0;
> > u16 vlan;
> > int i;
> >
> > for (i = 0; i < ETH_ALEN; i++)
> > srcmac = (srcmac << 8) | mac_hdr->h_source[i];
> >
> > if (!skb_vlan_tag_present(skb))
> > return srcmac;
> >
> > vlan = skb_vlan_tag_get(skb);
> >
> > return vlan ^ srcmac;
> > }
> >
> > Then the documentation is spot-on, and we're future-proof, though
> > marginally less performant in calculating the hash, which may have been a
> > consideration when the original function was written, but is probably
> > basically irrelevant w/modern systems...
>
> No preference, especially if bond_eth_hash() already uses the last byte.
> Just make sure the choice is explained in the commit message.
I've sold myself on using the full MAC, because if there's no vlan tag
present, mac is the only thing used for the hash, increasing the chances
of getting the same hash for two different interfaces, which won't happen
if we've got the full MAC. Of course, I'm not sure why someone would be
using this xmit hash outside of the very particular use-case that includes
VLANs, but people do strange things...
--
Jarod Wilson
jarod@redhat.com
next prev parent reply other threads:[~2021-01-14 21:43 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-18 19:30 [RFC PATCH net-next] bonding: add a vlan+srcmac tx hashing option Jarod Wilson
2020-12-19 0:18 ` Jay Vosburgh
2021-01-08 0:03 ` Jarod Wilson
2021-01-12 21:12 ` Jarod Wilson
2021-01-12 21:39 ` Jay Vosburgh
2021-01-12 22:32 ` Jarod Wilson
2020-12-28 10:11 ` Jiri Pirko
2021-01-07 23:58 ` Jarod Wilson
2021-01-08 13:12 ` Jiri Pirko
2021-01-08 15:21 ` Jarod Wilson
2021-01-15 2:02 ` question about bonding mode 4 moyufeng
2021-01-23 6:10 ` moyufeng
2021-01-29 19:11 ` Jay Vosburgh
2021-01-30 9:41 ` moyufeng
2021-01-13 22:35 ` [PATCH net-next v2] bonding: add a vlan+mac tx hashing option Jarod Wilson
2021-01-13 23:41 ` [PATCH iproute2] bond: support xmit_hash_policy=vlan+mac Jarod Wilson
2021-01-15 15:12 ` Jarod Wilson
2021-01-15 19:21 ` [PATCH iproute2 v2] bond: support xmit_hash_policy=vlan+srcmac Jarod Wilson
2021-01-23 18:35 ` David Ahern
2021-01-14 1:58 ` [PATCH net-next v2] bonding: add a vlan+mac tx hashing option Jakub Kicinski
2021-01-14 21:11 ` Jarod Wilson
2021-01-14 21:23 ` Jakub Kicinski
2021-01-14 21:42 ` Jarod Wilson [this message]
2021-01-14 21:54 ` Jay Vosburgh
2021-01-15 15:08 ` Jarod Wilson
2021-01-15 19:21 ` [PATCH net-next v3] bonding: add a vlan+srcmac " Jarod Wilson
2021-01-18 23:10 ` David Ahern
2021-01-19 1:04 ` Jarod Wilson
2021-01-19 1:09 ` [PATCH net-next v4] " Jarod Wilson
2021-01-20 6:10 ` patchwork-bot+netdevbpf
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=20210114214203.GI1171031@redhat.com \
--to=jarod@redhat.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=j.vosburgh@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tadavis@lbl.gov \
--cc=vfalico@gmail.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;
as well as URLs for NNTP newsgroup(s).