DPDK patches and discussions
 help / color / mirror / Atom feed
From: Isaac Boukris <iboukris@gmail.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>
Cc: dev@dpdk.org, stephen@networkplumber.org, mb@smartsharesystems.com
Subject: Re: [PATCH] net/tap: add new macpair option for split MAC address
Date: Mon, 30 Sep 2024 16:28:19 +0300	[thread overview]
Message-ID: <CAC-fF8SBjNeyFhLdCQ1YxNMgGn_X1GX37BsqkP+z8Mrex1JafQ@mail.gmail.com> (raw)
In-Reply-To: <09ab8aa9-db27-45a7-8178-2595de57da7f@amd.com>

Hi,

On Mon, Sep 30, 2024 at 12:55 AM 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=4675<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!

  reply	other threads:[~2024-09-30 13:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-17 11:51 Isaac Boukris
2024-09-17 12:14 ` Isaac Boukris
2024-09-29 21:54 ` Ferruh Yigit
2024-09-30 13:28   ` 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-fF8SBjNeyFhLdCQ1YxNMgGn_X1GX37BsqkP+z8Mrex1JafQ@mail.gmail.com \
    --to=iboukris@gmail.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --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).