DPDK patches and discussions
 help / color / mirror / Atom feed
From: Isaac Boukris <iboukris@gmail.com>
To: dev@dpdk.org
Cc: stephen@networkplumber.org, mb@smartsharesystems.com
Subject: Re: [PATCH] net/tap: add new macpair option for split MAC address
Date: Tue, 17 Sep 2024 15:14:13 +0300	[thread overview]
Message-ID: <CAC-fF8Tp4W5x45pqhyKt6F7=XBrw_PA2uSv8ZbqadSY9Rn1R5A@mail.gmail.com> (raw)
In-Reply-To: <20240917115147.378146-1-iboukris@gmail.com>

Hi,

This is a V2 addressing previous comments, I mistakenly passed the -v2
to send-mail instead of format-patch..

Thanks!

On Tue, Sep 17, 2024 at 2:52 PM Isaac Boukris <iboukris@gmail.com> wrote:
>
> Normally, the MAC address of the kernel interface is the same as in the
> interface in dpdk, as they represent the same interface. It is useful
> to allow viewing them as separate connected interfaces (like ip's veth).
>
> This solves a problem I have running a freebsd-based IPv6 stack on top
> of dpdk and using the tap interface, as both the kernel and freebsd
> stacks configure the MAC derived IPv6 address on the interface (as can
> be seen with ifconfig for the kernel), and they both complain about
> duplicate IPv6 address and the freebsd disables IPv6 as a result.
>
> Signed-off-by: Isaac Boukris <iboukris@gmail.com>
> ---
>  doc/guides/nics/tap.rst       | 18 +++++++++++++++++
>  drivers/net/tap/rte_eth_tap.c | 37 ++++++++++++++++++++++++++++++-----
>  drivers/net/tap/rte_eth_tap.h |  1 +
>  3 files changed, 51 insertions(+), 5 deletions(-)
>
> diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
> index f01663c700..fd936c6084 100644
> --- a/doc/guides/nics/tap.rst
> +++ b/doc/guides/nics/tap.rst
> @@ -71,6 +71,24 @@ But this behavior can be overridden by the use of the persist flag, example::
>
>    --vdev=net_tap0,iface=tap0,persist ...
>
> +Normally, the MAC address of the kernel interface is the same as in the
> +interface in dpdk, as they represent the same interface. If a MAC address is set
> +by the dpdk application using ``rte_eth_dev_default_mac_addr_set()`` then the
> +kernel interface changes accordingly (but not vice versa).
> +
> +If the ``macpair`` option is given, then the MAC address of the kernel
> +interface is initially set to a different random MAC address and it is no
> +longer altered by dpdk. This allows to view the two interfaces as separate
> +connected interfaces, similar to linux's veth pair interfaces. For instance,
> +you can configure an IP address on the kernel interface with the ``ip`` command
> +in the same subnet as the one used in dpdk and use it as next gateway.
> +
> +The ``macpair`` options is incompatible with the ``remote`` option (see above).
> +
> +Example::
> +
> +    --vdev=net_tap0,iface=tap0,macpair
> +
>
>  TUN devices
>  -----------
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index c5af5751f6..3cdd130092 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -56,6 +56,7 @@
>  #define ETH_TAP_MAC_ARG         "mac"
>  #define ETH_TAP_MAC_FIXED       "fixed"
>  #define ETH_TAP_PERSIST_ARG     "persist"
> +#define ETH_TAP_MACPAIR_ARG     "macpair"
>
>  #define ETH_TAP_USR_MAC_FMT     "xx:xx:xx:xx:xx:xx"
>  #define ETH_TAP_CMP_MAC_FMT     "0123456789ABCDEFabcdef"
> @@ -95,6 +96,7 @@ static const char *valid_arguments[] = {
>         ETH_TAP_REMOTE_ARG,
>         ETH_TAP_MAC_ARG,
>         ETH_TAP_PERSIST_ARG,
> +       ETH_TAP_MACPAIR_ARG,
>         NULL
>  };
>
> @@ -1391,6 +1393,12 @@ tap_mac_set(struct rte_eth_dev *dev, struct rte_ether_addr *mac_addr)
>                         dev->device->name);
>                 return -EINVAL;
>         }
> +
> +       if (pmd->mac_pair) {
> +               rte_ether_addr_copy(&pmd->eth_addr, mac_addr);
> +               return 0;
> +       }
> +
>         /* Check the actual current MAC address on the tap netdevice */
>         ret = tap_ioctl(pmd, SIOCGIFHWADDR, &ifr, 0, LOCAL_ONLY);
>         if (ret < 0)
> @@ -1915,7 +1923,7 @@ static const struct eth_dev_ops ops = {
>  static int
>  eth_dev_tap_create(struct rte_vdev_device *vdev, const char *tap_name,
>                    char *remote_iface, struct rte_ether_addr *mac_addr,
> -                  enum rte_tuntap_type type, int persist)
> +                  enum rte_tuntap_type type, int persist, int mac_pair)
>  {
>         int numa_node = rte_socket_id();
>         struct rte_eth_dev *dev;
> @@ -2023,12 +2031,20 @@ eth_dev_tap_create(struct rte_vdev_device *vdev, const char *tap_name,
>         if (pmd->type == ETH_TUNTAP_TYPE_TAP) {
>                 memset(&ifr, 0, sizeof(struct ifreq));
>                 ifr.ifr_hwaddr.sa_family = AF_LOCAL;
> -               rte_memcpy(ifr.ifr_hwaddr.sa_data, &pmd->eth_addr,
> -                               RTE_ETHER_ADDR_LEN);
> +
> +               if (mac_pair) {
> +                       rte_eth_random_addr((uint8_t *)ifr.ifr_hwaddr.sa_data);
> +               } else {
> +                       memcpy(ifr.ifr_hwaddr.sa_data, &pmd->eth_addr,
> +                              RTE_ETHER_ADDR_LEN);
> +               }
> +
>                 if (tap_ioctl(pmd, SIOCSIFHWADDR, &ifr, 0, LOCAL_ONLY) < 0)
>                         goto error_exit;
>         }
>
> +       pmd->mac_pair = mac_pair;
> +
>         /* Make network device persist after application exit */
>         pmd->persist = persist;
>
> @@ -2306,7 +2322,7 @@ rte_pmd_tun_probe(struct rte_vdev_device *dev)
>         TAP_LOG(DEBUG, "Initializing pmd_tun for %s", name);
>
>         ret = eth_dev_tap_create(dev, tun_name, remote_iface, 0,
> -                                ETH_TUNTAP_TYPE_TUN, 0);
> +                                ETH_TUNTAP_TYPE_TUN, 0, 0);
>
>  leave:
>         if (ret == -1) {
> @@ -2429,6 +2445,7 @@ rte_pmd_tap_probe(struct rte_vdev_device *dev)
>         struct rte_eth_dev *eth_dev;
>         int tap_devices_count_increased = 0;
>         int persist = 0;
> +       int mac_pair = 0;
>
>         name = rte_vdev_device_name(dev);
>         params = rte_vdev_device_args(dev);
> @@ -2504,6 +2521,16 @@ rte_pmd_tap_probe(struct rte_vdev_device *dev)
>                                         goto leave;
>                         }
>
> +                       if (rte_kvargs_count(kvlist, ETH_TAP_MACPAIR_ARG) == 1) {
> +                               if (strlen(remote_iface)) {
> +                                       TAP_LOG(ERR, "mac pair not supported "
> +                                                    "with remote interface.");
> +                                       ret = -1;
> +                                       goto leave;
> +                               }
> +                               mac_pair = 1;
> +                       }
> +
>                         if (rte_kvargs_count(kvlist, ETH_TAP_MAC_ARG) == 1) {
>                                 ret = rte_kvargs_process(kvlist,
>                                                          ETH_TAP_MAC_ARG,
> @@ -2533,7 +2560,7 @@ rte_pmd_tap_probe(struct rte_vdev_device *dev)
>         tap_devices_count++;
>         tap_devices_count_increased = 1;
>         ret = eth_dev_tap_create(dev, tap_name, remote_iface, &user_mac,
> -                                ETH_TUNTAP_TYPE_TAP, persist);
> +                                ETH_TUNTAP_TYPE_TAP, persist, mac_pair);
>
>  leave:
>         if (ret == -1) {
> diff --git a/drivers/net/tap/rte_eth_tap.h b/drivers/net/tap/rte_eth_tap.h
> index ce4322ad04..5a33698f76 100644
> --- a/drivers/net/tap/rte_eth_tap.h
> +++ b/drivers/net/tap/rte_eth_tap.h
> @@ -72,6 +72,7 @@ struct pmd_internals {
>         char name[RTE_ETH_NAME_MAX_LEN];  /* Internal Tap device name */
>         int type;                         /* Type field - TUN|TAP */
>         int persist;                      /* 1 if keep link up, else 0 */
> +       int mac_pair;                     /* 1 if mac pair enabled, else 0 */
>         struct rte_ether_addr eth_addr;   /* Mac address of the device port */
>         struct ifreq remote_initial_flags;/* Remote netdevice flags on init */
>         int remote_if_index;              /* remote netdevice IF_INDEX */
> --
> 2.45.0
>

  reply	other threads:[~2024-09-17 12:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-17 11:51 Isaac Boukris
2024-09-17 12:14 ` Isaac Boukris [this message]
  -- strict thread matches above, loose matches on Subject: below --
2024-09-16 17:38 Isaac Boukris
2024-09-17  3:34 ` Stephen Hemminger
2024-09-17  3:36 ` Stephen Hemminger
2024-09-17  6:48   ` Isaac Boukris
2024-09-17  7:38     ` Morten Brørup

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='CAC-fF8Tp4W5x45pqhyKt6F7=XBrw_PA2uSv8ZbqadSY9Rn1R5A@mail.gmail.com' \
    --to=iboukris@gmail.com \
    --cc=dev@dpdk.org \
    --cc=mb@smartsharesystems.com \
    --cc=stephen@networkplumber.org \
    /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).