From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 1A0ED45A68;
	Mon, 30 Sep 2024 15:28:34 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 03CB6402BB;
	Mon, 30 Sep 2024 15:28:34 +0200 (CEST)
Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com
 [209.85.216.50]) by mails.dpdk.org (Postfix) with ESMTP id C08FF4014F
 for <dev@dpdk.org>; Mon, 30 Sep 2024 15:28:32 +0200 (CEST)
Received: by mail-pj1-f50.google.com with SMTP id
 98e67ed59e1d1-2e07d85e956so3752441a91.3
 for <dev@dpdk.org>; Mon, 30 Sep 2024 06:28:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1727702912; x=1728307712; darn=dpdk.org;
 h=content-transfer-encoding:cc:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:from:to:cc:subject:date
 :message-id:reply-to;
 bh=oHtgQBOCtiWwZGOh+TZfBzfmUWHcAzO2FZetcvr6eBw=;
 b=ZWo4/ocDdZrHDFXz9hwjtazZDd0uLQlKjr6u+ut6YgvMF+Qu8wyod/+I9ZdRlQFqKX
 JwXrtLVsATxvZBbQLeT9WhyH0dJ7ebU1dThLNAuxqYXrHWYIiZTfj4QWYRdYlyDzHOk0
 Rw95KQxRdA+/wuYTUZw/gHZTHRSsc+1Fn/6op5WmjJrRJJJ9WmKdypGaZKYdSDxwwlno
 EKVI0mCtnm7+LYGRmXnJi7jDXkTktoLISgfmRylZo+e7Q/V41iZb80bbYc8MsXyE9tqE
 xciwe6g5hBZa6UQ4+9bRHitaV+/wbkiSOdqkejfZo8VzcOsIdtRqfN1s6gvlO8ahNSz+
 Pk6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1727702912; x=1728307712;
 h=content-transfer-encoding:cc:to:subject:message-id:date:from
 :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=oHtgQBOCtiWwZGOh+TZfBzfmUWHcAzO2FZetcvr6eBw=;
 b=XFyKYBBtgf5OoZQQYpkjcrnWHznJi8WA6V6aZPoMXDtn70bIdtsFh+B/UgCSNupuRu
 qLIHbMdIAvGjcBaJwh2CSW5Go67In8JreCSCSrKo+FYuBpl9ti6ne8yGKXhGlbyh7DEQ
 0P41GVRAfCj+WqqvlYtiYjFhh2/XYhakeSOEHexF4S1/E2XOFJELz9lP+D5N7ZFvYMac
 LCeQqBTga5MNisez2RB0arRS9XDFi7ej5g49GtNCP+lMlIi8nza+yooNWpT+E6ZWXUYG
 r3R66gYi0GKMar/sTKuA45T2O190sjbQ6OQqzpzn6kLqfDbhTFQuwiEhLwo5CGRZZktY
 H2zA==
X-Gm-Message-State: AOJu0Ywc+JPdJj3JXvauKhyDTcD9UnBWRKg+CxQSyCkCc+keAFLN3/gW
 o76TZhGhjTh14xrH+pSFU3A1CtI2gjn5Ku9UJDSH9JjAqg80PvzTCvL5EY6kOqhi8DO5ye5QsnC
 VTbNkAClmcyKpUcaY/hvaajGPGyhwYcqz
X-Google-Smtp-Source: AGHT+IEBUMq9jpBaZGYN+iRt0fDw+KiXFxTN6ba1nc3McJAq1YTn+JB7CiAWmHJTbhO7INyTp+9GR3V20i/bepjLdh4=
X-Received: by 2002:a17:90b:3546:b0:2da:5edd:c165 with SMTP id
 98e67ed59e1d1-2e0b8ea136dmr14297293a91.30.1727702911776; Mon, 30 Sep 2024
 06:28:31 -0700 (PDT)
MIME-Version: 1.0
References: <20240917115147.378146-1-iboukris@gmail.com>
 <09ab8aa9-db27-45a7-8178-2595de57da7f@amd.com>
In-Reply-To: <09ab8aa9-db27-45a7-8178-2595de57da7f@amd.com>
From: Isaac Boukris <iboukris@gmail.com>
Date: Mon, 30 Sep 2024 16:28:19 +0300
Message-ID: <CAC-fF8SBjNeyFhLdCQ1YxNMgGn_X1GX37BsqkP+z8Mrex1JafQ@mail.gmail.com>
Subject: Re: [PATCH] net/tap: add new macpair option for split MAC address
To: Ferruh Yigit <ferruh.yigit@amd.com>
Cc: dev@dpdk.org, stephen@networkplumber.org, mb@smartsharesystems.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

Hi,

On Mon, Sep 30, 2024 at 12:55=E2=80=AFAM Ferruh Yigit <ferruh.yigit@amd.com=
> wrote:
>
> 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?

It derives it from the MAC address, which dpdk sets on it via ioclt,
to be the same as the dpdk interface.

As soon as dpdk is up, the interface has this IP configured:

ifconfig dpdk0
dpdk0: flags=3D4675<UP,BROADCAST,RUNNING,ALLMULTI,MULTICAST>  mtu 1500
        inet6 fe80::c830:cff:feda:9762  prefixlen 64  scopeid 0x20<link>
        ether ca:30:0c:da:97:62  txqueuelen 1000  (Ethernet)
        RX packets 5  bytes 434 (434.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3  bytes 266 (266.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

dmesg showing the conflict with the stack running on dpdk:
IPv6: dpdk0: IPv6 duplicate address fe80::c830:cff:feda:9762 used by
ca:30:0c:da:97:62 detected!

> 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?

I'll take a look at the test-suite and try to come up with something better=
.

Thanks!