Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230531172158.90406-1-jon@nutanix.com> <CANn89iLE1d=MuSMTisEbLh6Q_c4rjagd8xuRj0PC-4ua0pDRPA@mail.gmail.com>
 <30861EDF-D063-43C7-94A7-9C3C5ED13E54@nutanix.com>
In-Reply-To: <30861EDF-D063-43C7-94A7-9C3C5ED13E54@nutanix.com>
From:   Eric Dumazet <edumazet@google.com>
Date:   Wed, 31 May 2023 20:00:50 +0200
Message-ID: <CANn89i+EKgtVnnq-LqtmHXd5Yg2WMVn5Uw+F7zM0jPRdaj3wsQ@mail.gmail.com>
Subject: Re: [PATCH] flow_dissector: introduce skb_get_hash_symmetric()
To:     Jon Kohler <jon@nutanix.com>
Cc:     "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Pavel Begunkov <asml.silence@gmail.com>,
        Richard Gobert <richardbgobert@gmail.com>,
        Menglong Dong <imagedong@tencent.com>,
        Wojciech Drewek <wojciech.drewek@intel.com>,
        Guillaume Nault <gnault@redhat.com>,
        John Fastabend <john.fastabend@gmail.com>,
        Stanislav Fomichev <sdf@google.com>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Shmulik Ladkani <shmulik.ladkani@gmail.com>,
        Qingqing Yang <qingqing.yang@broadcom.com>,
        Daniel Xu <dxu@dxuuu.xyz>, Felix Fietkau <nbd@nbd.name>,
        Ludovic Cintrat <ludovic.cintrat@gatewatcher.com>,
        Jason Wang <jasowang@redhat.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, May 31, 2023 at 7:47=E2=80=AFPM Jon Kohler <jon@nutanix.com> wrote:
>
>
>
> > On May 31, 2023, at 1:33 PM, Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Wed, May 31, 2023 at 7:22=E2=80=AFPM Jon Kohler <jon@nutanix.com> wr=
ote:
> >>
> >> tun.c changed from skb_get_hash() to __skb_get_hash_symmetric() on
> >> commit feec084a7cf4 ("tun: use symmetric hash"), which exposes an
> >> overhead for OVS datapath, where ovs_dp_process_packet() has to
> >> calculate the hash again because __skb_get_hash_symmetric() does not
> >> retain the hash that it calculates.
> >>
> >> Introduce skb_get_hash_symmetric(), which will get and save the hash
> >> in one go, so that calcuation work does not go to waste, and plumb it
> >> into tun.c.
> >>
> >> Fixes: feec084a7cf4 ("tun: use symmetric hash")
> >
> >
> >> Signed-off-by: Jon Kohler <jon@nutanix.com>
> >> CC: Jason Wang <jasowang@redhat.com>
> >> CC: David S. Miller <davem@davemloft.net>
> >> ---
> >>
> >
> >> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> >> index 0b40417457cd..8112b1ab5735 100644
> >> --- a/include/linux/skbuff.h
> >> +++ b/include/linux/skbuff.h
> >> @@ -1474,6 +1474,7 @@ __skb_set_sw_hash(struct sk_buff *skb, __u32 has=
h, bool is_l4)
> >>
> >> void __skb_get_hash(struct sk_buff *skb);
> >> u32 __skb_get_hash_symmetric(const struct sk_buff *skb);
> >> +u32 skb_get_hash_symmetric(struct sk_buff *skb);
> >> u32 skb_get_poff(const struct sk_buff *skb);
> >> u32 __skb_get_poff(const struct sk_buff *skb, const void *data,
> >>                   const struct flow_keys_basic *keys, int hlen);
> >> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> >> index 25fb0bbc310f..d8c0e804bbfe 100644
> >> --- a/net/core/flow_dissector.c
> >> +++ b/net/core/flow_dissector.c
> >> @@ -1747,6 +1747,35 @@ u32 __skb_get_hash_symmetric(const struct sk_bu=
ff *skb)
> >> }
> >> EXPORT_SYMBOL_GPL(__skb_get_hash_symmetric);
> >>
> >> +/**
> >> + * skb_get_hash_symmetric: calculate and set a flow hash in @skb, usi=
ng
> >> + * flow_keys_dissector_symmetric.
> >> + * @skb: sk_buff to calculate flow hash from
> >> + *
> >> + * This function is similar to __skb_get_hash_symmetric except that i=
t
> >> + * retains the hash within the skb, such that it can be reused withou=
t
> >> + * being recalculated later.
> >> + */
> >> +u32 skb_get_hash_symmetric(struct sk_buff *skb)
> >> +{
> >> +       struct flow_keys keys;
> >> +       u32 hash;
> >> +
> >> +       __flow_hash_secret_init();
> >> +
> >> +       memset(&keys, 0, sizeof(keys));
> >> +       __skb_flow_dissect(NULL, skb, &flow_keys_dissector_symmetric,
> >> +                          &keys, NULL, 0, 0, 0,
> >> +                          FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL);
> >> +
> >> +       hash =3D __flow_hash_from_keys(&keys, &hashrnd);
> >> +
> >> +       __skb_set_sw_hash(skb, hash, flow_keys_have_l4(&keys));
> >> +
> >> +       return hash;
> >> +}
> >> +EXPORT_SYMBOL_GPL(skb_get_hash_symmetric);
> >> +
> >
> > Why copy/pasting __skb_get_hash_symmetric() ?
> >
> > Can you reuse it ?
>
> Not directly, because to use __skb_set_sw_hash requires struct flow_keys
> when using flow_keys_have_l4(). __skb_get_hash_symmetric() does not
> take or return that struct, so we=E2=80=99d either have to refactor that =
(and its callers)
> or introduce yet another function and consolidate down to that =E2=80=9Cn=
ew one=E2=80=9D.
>
> I played around with that exact thought by taking the functional guts out=
 of
> __skb_get_hash_symmetric, making it a new static function, plumbing that
> into __skb_get_hash_symmetric and this new skb_get_hash_symmetric, but
> the LOC churn was basically the same and it felt a bit worse than just a
> copy/paste.
>
> Alternatively, if it turned out that flow_keys_have_l4() wasn=E2=80=99t i=
mportant, we
> Could simply set that to false and then reuse __skb_get_hash_symmetric
> in a trivial manner. I couldn=E2=80=99t quite figure out if L4 flag was n=
ecessary, so I
> went the safe(maybe?) route and copy/paste instead.
>
> Happy to take suggestions either way!

There are 6 callers of __skb_get_hash_symmetric()

I would convert __skb_get_hash_symmetric()  to

skb_get_hash_symmetric(struct sk_buff *skb, bool record_hash)