Re: [PATCH] net/tap: add new macpair option for split MAC address

[Ferruh Yigit <ferruh.yigit@amd.com>]

On 9/17/2024 12:51 PM, Isaac Boukris 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.
> 

How kernel side knows about the IPv6 address DPDK side uses, what is
your tap usecase?


> 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).
> +
>

I can see 'macpair' is coming from "veth pair" above, but I don't think
it is very explanatory in the context of tap. Do you have any more
suggestion?

Another concern is how to test this, tap PMD got multiple arguments now,
and as the pmd keeps getting more updates and features, how can we sure
this devarg usecase is not broken?