All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Fomichev <sdf@google.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
	martin.lau@kernel.org, ast@kernel.org, daniel@iogearbox.net,
	alexandr.lobakin@intel.com, larysa.zaremba@intel.com,
	xdp-hints@xdp-project.net, anthony.l.nguyen@intel.com,
	yoong.siang.song@intel.com, boon.leong.ong@intel.com,
	intel-wired-lan@lists.osuosl.org, pabeni@redhat.com,
	jesse.brandeburg@intel.com, kuba@kernel.org, edumazet@google.com,
	john.fastabend@gmail.com, hawk@kernel.org, davem@davemloft.net
Subject: Re: [PATCH bpf RFC 1/4] xdp: rss hash types representation
Date: Tue, 28 Mar 2023 14:58:52 -0700	[thread overview]
Message-ID: <ZCNjHAY81gS02FVW@google.com> (raw)
In-Reply-To: <168003455815.3027256.7575362149566382055.stgit@firesoul>

On 03/28, Jesper Dangaard Brouer wrote:
> The RSS hash type specifies what portion of packet data NIC hardware used
> when calculating RSS hash value. The RSS types are focused on Internet
> traffic protocols at OSI layers L3 and L4. L2 (e.g. ARP) often get hash
> value zero and no RSS type. For L3 focused on IPv4 vs. IPv6, and L4
> primarily TCP vs UDP, but some hardware supports SCTP.

> Hardware RSS types are differently encoded for each hardware NIC. Most
> hardware represent RSS hash type as a number. Determining L3 vs L4 often
> requires a mapping table as there often isn't a pattern or sorting
> according to ISO layer.

> The patch introduce a XDP RSS hash type (xdp_rss_hash_type) that can both
> be seen as a number that is ordered according by ISO layer, and can be bit
> masked to separate IPv4 and IPv6 types for L4 protocols. Room is available
> for extending later while keeping these properties. This maps and unifies
> difference to hardware specific hashes.

Looks good overall. Any reason we're making this specific layout?
Why not simply the following?

enum {
	XDP_RSS_TYPE_NONE = 0,
	XDP_RSS_TYPE_IPV4 = BIT(0),
	XDP_RSS_TYPE_IPV6 = BIT(1),
	/* IPv6 with extension header. */
	/* let's note ^^^ it in the UAPI? */
	XDP_RSS_TYPE_IPV6_EX = BIT(2),
	XDP_RSS_TYPE_UDP = BIT(3),
	XDP_RSS_TYPE_TCP = BIT(4),
	XDP_RSS_TYPE_SCTP = BIT(5),
}

And then using XDP_RSS_TYPE_IPV4|XDP_RSS_TYPE_UDP vs XDP_RSS_TYPE_IPV6|XXX ?

> This proposal change the kfunc API bpf_xdp_metadata_rx_hash() to return
> this RSS hash type on success.

> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
>   include/net/xdp.h |   51  
> +++++++++++++++++++++++++++++++++++++++++++++++++++
>   net/core/xdp.c    |    4 +++-
>   2 files changed, 54 insertions(+), 1 deletion(-)

> diff --git a/include/net/xdp.h b/include/net/xdp.h
> index 5393b3ebe56e..63f462f5ea7f 100644
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -8,6 +8,7 @@

>   #include <linux/skbuff.h> /* skb_shared_info */
>   #include <uapi/linux/netdev.h>
> +#include <linux/bitfield.h>

>   /**
>    * DOC: XDP RX-queue information
> @@ -396,6 +397,56 @@ XDP_METADATA_KFUNC_xxx
>   MAX_XDP_METADATA_KFUNC,
>   };

> +/* For partitioning of xdp_rss_hash_type */
> +#define RSS_L3		GENMASK(2,0) /* 3-bits = values between 1-7 */
> +#define L4_BIT		BIT(3)       /* 1-bit - L4 indication */
> +#define RSS_L4_IPV4	GENMASK(6,4) /* 3-bits */
> +#define RSS_L4_IPV6	GENMASK(9,7) /* 3-bits */
> +#define RSS_L4		GENMASK(9,3) /* = 7-bits - covering L4 IPV4+IPV6 */
> +#define L4_IPV6_EX_BIT	BIT(9)       /* 1-bit - L4 IPv6 with Extension  
> hdr */
> +				     /* 11-bits in total */
> +
> +/* The XDP RSS hash type (xdp_rss_hash_type) can both be seen as a  
> number that
> + * is ordered according by ISO layer, and can be bit masked to separate  
> IPv4 and
> + * IPv6 types for L4 protocols. Room is available for extending later  
> while
> + * keeping above properties, as this need to cover NIC hardware RSS  
> types.
> + */
> +enum xdp_rss_hash_type {
> +	XDP_RSS_TYPE_NONE            = 0,
> +	XDP_RSS_TYPE_L2              = XDP_RSS_TYPE_NONE,
> +
> +	XDP_RSS_TYPE_L3_MASK         = RSS_L3,
> +	XDP_RSS_TYPE_L3_IPV4         = FIELD_PREP_CONST(RSS_L3, 1),
> +	XDP_RSS_TYPE_L3_IPV6         = FIELD_PREP_CONST(RSS_L3, 2),
> +	XDP_RSS_TYPE_L3_IPV6_EX      = FIELD_PREP_CONST(RSS_L3, 4),
> +
> +	XDP_RSS_TYPE_L4_MASK         = RSS_L4,
> +	XDP_RSS_TYPE_L4_SHIFT        = __bf_shf(RSS_L4),
> +	XDP_RSS_TYPE_L4_MASK_EX      = RSS_L4 | L4_IPV6_EX_BIT,
> +
> +	XDP_RSS_TYPE_L4_IPV4_MASK    = RSS_L4_IPV4,
> +	XDP_RSS_TYPE_L4_BIT          = L4_BIT,
> +	XDP_RSS_TYPE_L4_IPV4_TCP     = L4_BIT|FIELD_PREP_CONST(RSS_L4_IPV4, 1),
> +	XDP_RSS_TYPE_L4_IPV4_UDP     = L4_BIT|FIELD_PREP_CONST(RSS_L4_IPV4, 2),
> +	XDP_RSS_TYPE_L4_IPV4_SCTP    = L4_BIT|FIELD_PREP_CONST(RSS_L4_IPV4, 3),
> +
> +	XDP_RSS_TYPE_L4_IPV6_MASK    = RSS_L4_IPV6,
> +	XDP_RSS_TYPE_L4_IPV6_TCP     = L4_BIT|FIELD_PREP_CONST(RSS_L4_IPV6, 1),
> +	XDP_RSS_TYPE_L4_IPV6_UDP     = L4_BIT|FIELD_PREP_CONST(RSS_L4_IPV6, 2),
> +	XDP_RSS_TYPE_L4_IPV6_SCTP    = L4_BIT|FIELD_PREP_CONST(RSS_L4_IPV6, 3),
> +
> +	XDP_RSS_TYPE_L4_IPV6_EX_MASK = L4_IPV6_EX_BIT,
> +	XDP_RSS_TYPE_L4_IPV6_TCP_EX  = XDP_RSS_TYPE_L4_IPV6_TCP |L4_IPV6_EX_BIT,
> +	XDP_RSS_TYPE_L4_IPV6_UDP_EX  = XDP_RSS_TYPE_L4_IPV6_UDP |L4_IPV6_EX_BIT,
> +	XDP_RSS_TYPE_L4_IPV6_SCTP_EX = XDP_RSS_TYPE_L4_IPV6_SCTP|L4_IPV6_EX_BIT,
> +};
> +#undef RSS_L3
> +#undef L4_BIT
> +#undef RSS_L4_IPV4
> +#undef RSS_L4_IPV6
> +#undef RSS_L4
> +#undef L4_IPV6_EX_BIT
> +
>   #ifdef CONFIG_NET
>   u32 bpf_xdp_metadata_kfunc_id(int id);
>   bool bpf_dev_bound_kfunc_id(u32 btf_id);
> diff --git a/net/core/xdp.c b/net/core/xdp.c
> index 7133017bcd74..81d41df30695 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -721,12 +721,14 @@ __bpf_kfunc int bpf_xdp_metadata_rx_timestamp(const  
> struct xdp_md *ctx, u64 *tim
>    * @hash: Return value pointer.
>    *
>    * Return:
> - * * Returns 0 on success or ``-errno`` on error.
> + * * Returns (positive) RSS hash **type** on success or ``-errno`` on  
> error.
> + * * ``enum xdp_rss_hash_type`` : RSS hash type
>    * * ``-EOPNOTSUPP`` : means device driver doesn't implement kfunc
>    * * ``-ENODATA``    : means no RX-hash available for this frame
>    */
>   __bpf_kfunc int bpf_xdp_metadata_rx_hash(const struct xdp_md *ctx, u32  
> *hash)
>   {
> +	BTF_TYPE_EMIT(enum xdp_rss_hash_type);
>   	return -EOPNOTSUPP;
>   }




WARNING: multiple messages have this Message-ID (diff)
From: Stanislav Fomichev <sdf@google.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: xdp-hints@xdp-project.net, martin.lau@kernel.org,
	daniel@iogearbox.net, larysa.zaremba@intel.com,
	netdev@vger.kernel.org, john.fastabend@gmail.com, ast@kernel.org,
	jesse.brandeburg@intel.com, edumazet@google.com,
	pabeni@redhat.com, yoong.siang.song@intel.com, kuba@kernel.org,
	boon.leong.ong@intel.com, anthony.l.nguyen@intel.com,
	bpf@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	davem@davemloft.net, hawk@kernel.org
Subject: Re: [Intel-wired-lan] [PATCH bpf RFC 1/4] xdp: rss hash types representation
Date: Tue, 28 Mar 2023 14:58:52 -0700	[thread overview]
Message-ID: <ZCNjHAY81gS02FVW@google.com> (raw)
In-Reply-To: <168003455815.3027256.7575362149566382055.stgit@firesoul>

On 03/28, Jesper Dangaard Brouer wrote:
> The RSS hash type specifies what portion of packet data NIC hardware used
> when calculating RSS hash value. The RSS types are focused on Internet
> traffic protocols at OSI layers L3 and L4. L2 (e.g. ARP) often get hash
> value zero and no RSS type. For L3 focused on IPv4 vs. IPv6, and L4
> primarily TCP vs UDP, but some hardware supports SCTP.

> Hardware RSS types are differently encoded for each hardware NIC. Most
> hardware represent RSS hash type as a number. Determining L3 vs L4 often
> requires a mapping table as there often isn't a pattern or sorting
> according to ISO layer.

> The patch introduce a XDP RSS hash type (xdp_rss_hash_type) that can both
> be seen as a number that is ordered according by ISO layer, and can be bit
> masked to separate IPv4 and IPv6 types for L4 protocols. Room is available
> for extending later while keeping these properties. This maps and unifies
> difference to hardware specific hashes.

Looks good overall. Any reason we're making this specific layout?
Why not simply the following?

enum {
	XDP_RSS_TYPE_NONE = 0,
	XDP_RSS_TYPE_IPV4 = BIT(0),
	XDP_RSS_TYPE_IPV6 = BIT(1),
	/* IPv6 with extension header. */
	/* let's note ^^^ it in the UAPI? */
	XDP_RSS_TYPE_IPV6_EX = BIT(2),
	XDP_RSS_TYPE_UDP = BIT(3),
	XDP_RSS_TYPE_TCP = BIT(4),
	XDP_RSS_TYPE_SCTP = BIT(5),
}

And then using XDP_RSS_TYPE_IPV4|XDP_RSS_TYPE_UDP vs XDP_RSS_TYPE_IPV6|XXX ?

> This proposal change the kfunc API bpf_xdp_metadata_rx_hash() to return
> this RSS hash type on success.

> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
>   include/net/xdp.h |   51  
> +++++++++++++++++++++++++++++++++++++++++++++++++++
>   net/core/xdp.c    |    4 +++-
>   2 files changed, 54 insertions(+), 1 deletion(-)

> diff --git a/include/net/xdp.h b/include/net/xdp.h
> index 5393b3ebe56e..63f462f5ea7f 100644
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -8,6 +8,7 @@

>   #include <linux/skbuff.h> /* skb_shared_info */
>   #include <uapi/linux/netdev.h>
> +#include <linux/bitfield.h>

>   /**
>    * DOC: XDP RX-queue information
> @@ -396,6 +397,56 @@ XDP_METADATA_KFUNC_xxx
>   MAX_XDP_METADATA_KFUNC,
>   };

> +/* For partitioning of xdp_rss_hash_type */
> +#define RSS_L3		GENMASK(2,0) /* 3-bits = values between 1-7 */
> +#define L4_BIT		BIT(3)       /* 1-bit - L4 indication */
> +#define RSS_L4_IPV4	GENMASK(6,4) /* 3-bits */
> +#define RSS_L4_IPV6	GENMASK(9,7) /* 3-bits */
> +#define RSS_L4		GENMASK(9,3) /* = 7-bits - covering L4 IPV4+IPV6 */
> +#define L4_IPV6_EX_BIT	BIT(9)       /* 1-bit - L4 IPv6 with Extension  
> hdr */
> +				     /* 11-bits in total */
> +
> +/* The XDP RSS hash type (xdp_rss_hash_type) can both be seen as a  
> number that
> + * is ordered according by ISO layer, and can be bit masked to separate  
> IPv4 and
> + * IPv6 types for L4 protocols. Room is available for extending later  
> while
> + * keeping above properties, as this need to cover NIC hardware RSS  
> types.
> + */
> +enum xdp_rss_hash_type {
> +	XDP_RSS_TYPE_NONE            = 0,
> +	XDP_RSS_TYPE_L2              = XDP_RSS_TYPE_NONE,
> +
> +	XDP_RSS_TYPE_L3_MASK         = RSS_L3,
> +	XDP_RSS_TYPE_L3_IPV4         = FIELD_PREP_CONST(RSS_L3, 1),
> +	XDP_RSS_TYPE_L3_IPV6         = FIELD_PREP_CONST(RSS_L3, 2),
> +	XDP_RSS_TYPE_L3_IPV6_EX      = FIELD_PREP_CONST(RSS_L3, 4),
> +
> +	XDP_RSS_TYPE_L4_MASK         = RSS_L4,
> +	XDP_RSS_TYPE_L4_SHIFT        = __bf_shf(RSS_L4),
> +	XDP_RSS_TYPE_L4_MASK_EX      = RSS_L4 | L4_IPV6_EX_BIT,
> +
> +	XDP_RSS_TYPE_L4_IPV4_MASK    = RSS_L4_IPV4,
> +	XDP_RSS_TYPE_L4_BIT          = L4_BIT,
> +	XDP_RSS_TYPE_L4_IPV4_TCP     = L4_BIT|FIELD_PREP_CONST(RSS_L4_IPV4, 1),
> +	XDP_RSS_TYPE_L4_IPV4_UDP     = L4_BIT|FIELD_PREP_CONST(RSS_L4_IPV4, 2),
> +	XDP_RSS_TYPE_L4_IPV4_SCTP    = L4_BIT|FIELD_PREP_CONST(RSS_L4_IPV4, 3),
> +
> +	XDP_RSS_TYPE_L4_IPV6_MASK    = RSS_L4_IPV6,
> +	XDP_RSS_TYPE_L4_IPV6_TCP     = L4_BIT|FIELD_PREP_CONST(RSS_L4_IPV6, 1),
> +	XDP_RSS_TYPE_L4_IPV6_UDP     = L4_BIT|FIELD_PREP_CONST(RSS_L4_IPV6, 2),
> +	XDP_RSS_TYPE_L4_IPV6_SCTP    = L4_BIT|FIELD_PREP_CONST(RSS_L4_IPV6, 3),
> +
> +	XDP_RSS_TYPE_L4_IPV6_EX_MASK = L4_IPV6_EX_BIT,
> +	XDP_RSS_TYPE_L4_IPV6_TCP_EX  = XDP_RSS_TYPE_L4_IPV6_TCP |L4_IPV6_EX_BIT,
> +	XDP_RSS_TYPE_L4_IPV6_UDP_EX  = XDP_RSS_TYPE_L4_IPV6_UDP |L4_IPV6_EX_BIT,
> +	XDP_RSS_TYPE_L4_IPV6_SCTP_EX = XDP_RSS_TYPE_L4_IPV6_SCTP|L4_IPV6_EX_BIT,
> +};
> +#undef RSS_L3
> +#undef L4_BIT
> +#undef RSS_L4_IPV4
> +#undef RSS_L4_IPV6
> +#undef RSS_L4
> +#undef L4_IPV6_EX_BIT
> +
>   #ifdef CONFIG_NET
>   u32 bpf_xdp_metadata_kfunc_id(int id);
>   bool bpf_dev_bound_kfunc_id(u32 btf_id);
> diff --git a/net/core/xdp.c b/net/core/xdp.c
> index 7133017bcd74..81d41df30695 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -721,12 +721,14 @@ __bpf_kfunc int bpf_xdp_metadata_rx_timestamp(const  
> struct xdp_md *ctx, u64 *tim
>    * @hash: Return value pointer.
>    *
>    * Return:
> - * * Returns 0 on success or ``-errno`` on error.
> + * * Returns (positive) RSS hash **type** on success or ``-errno`` on  
> error.
> + * * ``enum xdp_rss_hash_type`` : RSS hash type
>    * * ``-EOPNOTSUPP`` : means device driver doesn't implement kfunc
>    * * ``-ENODATA``    : means no RX-hash available for this frame
>    */
>   __bpf_kfunc int bpf_xdp_metadata_rx_hash(const struct xdp_md *ctx, u32  
> *hash)
>   {
> +	BTF_TYPE_EMIT(enum xdp_rss_hash_type);
>   	return -EOPNOTSUPP;
>   }



_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  reply	other threads:[~2023-03-28 21:58 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-28 20:15 [PATCH bpf RFC 0/4] XDP-hints: API change for RX-hash kfunc bpf_xdp_metadata_rx_hash Jesper Dangaard Brouer
2023-03-28 20:15 ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-03-28 20:15 ` [PATCH bpf RFC 1/4] xdp: rss hash types representation Jesper Dangaard Brouer
2023-03-28 20:15   ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-03-28 21:58   ` Stanislav Fomichev [this message]
2023-03-28 21:58     ` Stanislav Fomichev
2023-03-29 11:23     ` Jesper Dangaard Brouer
2023-03-29 11:23       ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-03-29 17:18       ` Stanislav Fomichev
2023-03-29 17:18         ` [Intel-wired-lan] " Stanislav Fomichev
2023-03-29 18:19         ` Jesper Dangaard Brouer
2023-03-29 18:19           ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-03-29 23:19           ` Stanislav Fomichev
2023-03-29 23:19             ` [Intel-wired-lan] " Stanislav Fomichev
2023-03-30  9:51             ` Jesper Dangaard Brouer
2023-03-30  9:51               ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-03-30 17:11               ` Stanislav Fomichev
2023-03-30 17:11                 ` [Intel-wired-lan] " Stanislav Fomichev
2023-03-30 18:52                 ` Jesper Dangaard Brouer
2023-03-30 18:52                   ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-03-29  8:10   ` Edward Cree
2023-03-29  8:10     ` [Intel-wired-lan] " Edward Cree
2023-03-29 12:13     ` [xdp-hints] " Jesper Dangaard Brouer
2023-03-29 12:13       ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-03-28 20:16 ` [PATCH bpf RFC 2/4] igc: bpf_xdp_metadata_rx_hash return xdp rss hash type Jesper Dangaard Brouer
2023-03-28 20:16   ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-03-28 20:16 ` [PATCH bpf RFC 3/4] veth: " Jesper Dangaard Brouer
2023-03-28 20:16   ` [Intel-wired-lan] " Jesper Dangaard Brouer
2023-03-28 20:16 ` [PATCH bpf RFC 4/4] mlx5: " Jesper Dangaard Brouer
2023-03-28 20:16   ` [Intel-wired-lan] " Jesper Dangaard Brouer

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=ZCNjHAY81gS02FVW@google.com \
    --to=sdf@google.com \
    --cc=alexandr.lobakin@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=ast@kernel.org \
    --cc=boon.leong.ong@intel.com \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hawk@kernel.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=larysa.zaremba@intel.com \
    --cc=martin.lau@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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 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.