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
>
next prev parent 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).