Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Mar 2017 22:28:51 +0100
From:      Vincenzo Maffione <v.maffione@gmail.com>
To:        Harry Schmalzbauer <freebsd@omnilan.de>
Cc:        freebsd-net <freebsd-net@freebsd.org>
Subject:   Re: [panic] netmap(4) and if_lagg(4)
Message-ID:  <CA%2B_eA9iajZOUFsnWKdodN7zMvst8wn0xViM4xxEx%2B41jw_0B3g@mail.gmail.com>
In-Reply-To: <58CC23F5.7060507@omnilan.de>
References:  <58CBCD7A.8060301@omnilan.de> <CA%2B_eA9iCT7evWUcZMA_ViKfrZnSHp3OpBTS5c4iJ9=ZjO-Pfgw@mail.gmail.com> <58CC23F5.7060507@omnilan.de>

next in thread | previous in thread | raw e-mail | index | archive | help
Two things here:

- We pushed an important fix to stable/11 1-2 months ago, that prevents
panic on emulated netmap mode. Maybe you are still getting that panic
because you are using an older stable/11 image, you should check.
- If you are using "software devices" like if_lagg or even vlan interfaces,
netmap and VALE won't help you a lot, because the drivers are not patched
for netmap (and cannot be).

You are right, VALE is great for guest-to-guest traffic, and for this you
don't need vale-ctl.

It's not by design that NIC must be set in promisc mode when attached to
VALE or used by netmap. But this is usually the case when you are using VMs
(that come with their own MACs).


Cheers,
  Vincenzo

2017-03-17 18:59 GMT+01:00 Harry Schmalzbauer <freebsd@omnilan.de>:

> Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 17.03.2017 18:29 (localt=
ime):
> > Hi,
> >   This is supposed to work because of the emulated netmap adapter.
> > By means of that, Netmap works on tap(4) interfaces if_bridge
> > interfaces, epairs, etc. Have you tried those to see if that works?
>
> Hello Vincenzo,
>
> thanks a lot for your attention!
>
> Yes, I tried various epair/tap setups.
> Description followes.
>
>
> > Maybe here the problem is that if_lagg is a "metadriver", which
> > interacts in a bad way with the emulated adapter, which needs to
> > intercept all the packets received from the driver.
>
> It seems it's a more generic problem to cloned interfaces, since I get
> the same panic when trying to add a em0.vlanN to vale.
>
> There are a lot of component's in my desired setup:
>
> 2 igb interfaces build one (LACP) lagg cloned if.
> Several cloned vlan children of that lagg interface shall handle IPs for
> jails without vnet.
> Then there are byhve guests, which are not that bandwidth and latency
> critical for frames leaving the host, but for guest-to-host and
> guest-to-guest connections, thus vale looks promising to me.
>
> Attaching the 2nd-gen-cloned vlan children of lagg(4) to vale, doesn't
> lead to panics, but I couldn't pass any frame. I see arp-who-has and
> also the answhers on the vlanIF, but it seems frames don't traverse vale.
>
> Attaching a 1st-gen cloned vlan(4) children of another em(4) interface,
> I get the same panic when trying lagg(4) to vale.
>
> The only working setup was:
>
> igb0 --|
>       lagg0 -                bridge0
> igb1 --|     |                |    |
>              |-> lagg0.101 ---|    |epair0a|epair0b--vale0port1
>              |                             |epair0b^-vale0port2
>              |-> lagg0.102                      vif0-vale0port3
>              |                                   |
>              |-> lagg0.103                       |
>              =E2=80=A6                     bhyve -s 5,virtio-net,vif0
>
> Attaching lagg0 to vale0 =3D panic
> Attaching lagg0.101 to vale0 =3D silence
> Attaching em0.101 to vale0 =3D same panic as with lagg0
> Attaching em0 to vale0 =3D silence with tagged frames
>  ifconfig em0 -vlanhwtag solves the latter, but this doesn't really
> help, because VID filtering inside the guest is no option, was just for
> testing.
>
> I'm running stable/11 as of today.
>
> Is it by design that the physical vale interface must be set to promisc
> mode?
>
> Thanks,
>
> -harry
>



--=20
Vincenzo Maffione



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B_eA9iajZOUFsnWKdodN7zMvst8wn0xViM4xxEx%2B41jw_0B3g>