All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robin Jarry" <rjarry@redhat.com>
To: "Vladimir Medvedkin" <vladimir.medvedkin@intel.com>, <dev@dpdk.org>
Cc: <mb@smartsharesystems.com>, <david.marchand@redhat.com>,
	<stephen@networkplumber.org>
Subject: Re: [PATCH v3] fib: network byte order IPv4 lookup
Date: Fri, 11 Oct 2024 12:32:22 +0200	[thread overview]
Message-ID: <D4SWPKOPRD5Z.87YIET3Y4AW@redhat.com> (raw)
In-Reply-To: <20241010112621.681773-1-vladimir.medvedkin@intel.com>

Hi Vladimir,

Vladimir Medvedkin, Oct 10, 2024 at 13:26:
> Previously when running rte_fib_lookup IPv4 addresses must have been in
> host byte order.
>
> This patch adds a new flag RTE_FIB_FLAG_LOOKUP_BE that can be passed on
> fib create, which will allow to have IPv4 in network byte order on
> lookup.
>
> Signed-off-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>

[snip]

> diff --git a/lib/fib/dir24_8.h b/lib/fib/dir24_8.h
> index 7125049f15..2c776e118f 100644
> --- a/lib/fib/dir24_8.h
> +++ b/lib/fib/dir24_8.h
> @@ -7,7 +7,9 @@
>  #define _DIR24_8_H_
>  
>  #include <stdalign.h>
> +#include <stdbool.h>
>  
> +#include <rte_byteorder.h>
>  #include <rte_prefetch.h>
>  #include <rte_branch_prediction.h>
>  
> @@ -237,6 +239,46 @@ dir24_8_lookup_bulk_uni(void *p, const uint32_t *ips,
>  	}
>  }
>  
> +#define BSWAP_MAX_LENGTH	64
> +
> +typedef void (*dir24_8_lookup_bulk_be_cb)(void *p, const uint32_t *ips,
> +	uint64_t *next_hops, const unsigned int n);
> +
> +static inline void
> +dir24_8_lookup_bulk_be(void *p, const uint32_t *ips,
> +	uint64_t *next_hops, const unsigned int n,
> +	dir24_8_lookup_bulk_be_cb cb)
> +{
> +	uint32_t le_ips[BSWAP_MAX_LENGTH];
> +	unsigned int i;
> +
> +	for (i = 0; i < n; i += BSWAP_MAX_LENGTH) {
> +		int j;
> +		for (j = 0; j < BSWAP_MAX_LENGTH && i + j < n; j++)
> +			le_ips[j] = rte_be_to_cpu_32(ips[i + j]);
> +
> +		cb(p, le_ips, next_hops + i, j);
> +	}

This should be a noop for big endian platforms. I'm not sure the 
complier will be smart enough to collapse the nested loops.

> +}
> +
> +#define DECLARE_BE_LOOKUP_FN(name)					\
> +static inline void							\
> +name##_be(void *p, const uint32_t *ips,					\
> +	uint64_t *next_hops, const unsigned int n)			\
> +{									\
> +	dir24_8_lookup_bulk_be(p, ips, next_hops, n, name);		\
> +}
> +
> +DECLARE_BE_LOOKUP_FN(dir24_8_lookup_bulk_1b)
> +DECLARE_BE_LOOKUP_FN(dir24_8_lookup_bulk_2b)
> +DECLARE_BE_LOOKUP_FN(dir24_8_lookup_bulk_4b)
> +DECLARE_BE_LOOKUP_FN(dir24_8_lookup_bulk_8b)
> +DECLARE_BE_LOOKUP_FN(dir24_8_lookup_bulk_0)
> +DECLARE_BE_LOOKUP_FN(dir24_8_lookup_bulk_1)
> +DECLARE_BE_LOOKUP_FN(dir24_8_lookup_bulk_2)
> +DECLARE_BE_LOOKUP_FN(dir24_8_lookup_bulk_3)
> +DECLARE_BE_LOOKUP_FN(dir24_8_lookup_bulk_uni)
> +
>  void *
>  dir24_8_create(const char *name, int socket_id, struct rte_fib_conf *conf);
>  
> @@ -244,7 +286,7 @@ void
>  dir24_8_free(void *p);
>  
>  rte_fib_lookup_fn_t
> -dir24_8_get_lookup_fn(void *p, enum rte_fib_lookup_type type);
> +dir24_8_get_lookup_fn(void *p, enum rte_fib_lookup_type type, bool be_addr);
>  
>  int
>  dir24_8_modify(struct rte_fib *fib, uint32_t ip, uint8_t depth,

[snip]

> diff --git a/lib/fib/rte_fib.h b/lib/fib/rte_fib.h
> index d7a5aafe53..1617235e85 100644
> --- a/lib/fib/rte_fib.h
> +++ b/lib/fib/rte_fib.h
> @@ -28,6 +28,9 @@ struct rte_rib;
>  /** Maximum depth value possible for IPv4 FIB. */
>  #define RTE_FIB_MAXDEPTH	32
>  
> +/** If set fib lookup is expecting ipv4 in network byte order */
> +#define RTE_FIB_FLAG_LOOKUP_BE	1

I think RTE_FIB_F_NETWORK_ORDER would be more appropriate.

> +
>  /** Type of FIB struct */
>  enum rte_fib_type {
>  	RTE_FIB_DUMMY,		/**< RIB tree based FIB */
> @@ -76,6 +79,7 @@ enum rte_fib_lookup_type {
>  /** FIB configuration structure */
>  struct rte_fib_conf {
>  	enum rte_fib_type type; /**< Type of FIB struct */
> +	unsigned int flags;

Maybe use an explicit int size for flags like uint32_t? I doubt we'll 
ever need more than 32 flags.

Also, maybe it would be better to add this field at the end to avoid 
breaking the API?

You forgot to add a doc string for that field:

    uint32_t flags; /**< Optional feature flags from RTE_FIB_F_* **/

Thanks!


  reply	other threads:[~2024-10-11 10:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-06 17:06 [PATCH] fib: network byte order IPv4 lookup Vladimir Medvedkin
2024-09-27 23:51 ` David Marchand
2024-09-30 15:07   ` David Marchand
2024-10-04 12:01     ` Vladimir Medvedkin
2024-10-08 17:33 ` [PATCH v2] " Vladimir Medvedkin
2024-10-10 11:26   ` [PATCH v3] " Vladimir Medvedkin
2024-10-11 10:32     ` Robin Jarry [this message]
2024-10-11 11:29     ` David Marchand
2024-10-11 14:33       ` David Marchand
2024-10-11 17:57     ` [PATCH v4] " Vladimir Medvedkin
2024-10-14 13:37       ` [PATCH v5] " Vladimir Medvedkin
2024-10-14 15:22         ` Stephen Hemminger
2024-10-14 16:59           ` David Marchand

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=D4SWPKOPRD5Z.87YIET3Y4AW@redhat.com \
    --to=rjarry@redhat.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=mb@smartsharesystems.com \
    --cc=stephen@networkplumber.org \
    --cc=vladimir.medvedkin@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.