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!