Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Jun 2017 00:43:01 +0200
From:      Vincenzo Maffione <v.maffione@gmail.com>
To:        Harry Schmalzbauer <freebsd@omnilan.de>
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Subject:   Re: vale uplink via vlan-if [Was: Re: Are ./valte-ctl and ./bridge friends or competitors?]
Message-ID:  <CA%2B_eA9h-L5RpNO9b4cJReQMUhhNhnUh86aMnEvx=owUM%2BTS8mA@mail.gmail.com>
In-Reply-To: <5926F74A.1000101@omnilan.de>
References:  <58CBA727.3040108@omnilan.de> <58CBBF7A.8050604@omnilan.de> <CA%2B_eA9jYxRoi2HPcVjKbifTM43nnHeMQGDmmQvsw5UdXtLmFug@mail.gmail.com> <58CC26CF.5050708@omnilan.de> <CA%2B_eA9j30Shp1QB%2B6UY1YRqsWKRo4xqPvDRnMHT25VQL4QhQ_Q@mail.gmail.com> <58CFA606.7090306@omnilan.de> <CA%2B_eA9hso4AKpFEJCXWHYYz5tbLx4jT2o=3c-3YrWM98ovB8%2BA@mail.gmail.com> <58D02259.9010101@omnilan.de> <CA%2B_eA9hxpevk%2BSJwJZCdnSsQu0iRBo52V5qC=225hVxQu04KyQ@mail.gmail.com> <5926F74A.1000101@omnilan.de>

next in thread | previous in thread | raw e-mail | index | archive | help
If VLAN interface do not work properly with VALE/netmap that's a bug of the
emulated adapter code in FreeBSD.
But in any case the approach is not the right one, since using the emulated
netmap adapter with VALE will make you lose most of the advantage of using
netmap in the first place.
(see my previous email).

Cheers,
  Vincenzo

2017-05-25 17:24 GMT+02:00 Harry Schmalzbauer <freebsd@omnilan.de>:

> Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 21.03.2017 19:05 (localt=
ime):
> > 2017-03-20 19:41 GMT+01:00 Harry Schmalzbauer <freebsd@omnilan.de>:
> >
> >> Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 20.03.2017 12:50
> (localtime):
> >> =E2=80=A6
> >>>> So to summarize for newbies exploring netmap(4) world in combination
> >>>> with physical uplinks and virtual interfaces, it's important to do t=
he
> >>>> following uplink NIC configuration (ifconfig(8)):
> >>>> -rxcsum -txcsum -rxcsum6 -txcsum6 -tso -lro promisc
> >>>>
> >>>
> >>> Exactly. This is mentioned at the very end of netmap(4):
> >>>
> >>> "netmap does not use features such as checksum offloading, TCP
> >> segmentation
> >>> offloading, encryption, VLAN encapsulation/decapsulation, etc.  When
> >> using
> >>> netmap to exchange packets with the host stack, make sure to disable
> >> these
> >>> features."
> >>>
> >>> But it is probably a good idea to add these example ifconfig
> instructions
> >>> somewhere (man page or at least the README in the netmap repo).
> >>>
> >>>
> >>>>
> >>>> I guess vlanhwtag, vlanhwfilter and vlanhwtso don't interfere, do
> they?
> >>>>
> >>>
> >>> Well, I think they interfere: if you receive a tagged packet and the
> NIC
> >>> strips the tag and puts it in the packet descriptor, then with netmap
> you
> >>> will see the untagged packet, and you wouldn't have a way to see the
> tag.
>
> Sorry picking this up again, but I'm stuck getting vale(4) productive :-(
>
> I took lagg(4) out of the game and configured my desired setup using
> if_bridge(4) at first.
>
> The physical uplink NIC is em0.
> The bridge/vale uplink is em0.232.
>
> hostB --switch-- em0-hostA
>                   |
>                   '- em0.232
>                       |
>                     bridge5-vmnet0
>                               |
>                              vtnet0-GUESTa <-tcpdump:
>
> 17:07:28.423768 00:a0:98:73:9f:42 > ff:ff:ff:ff:ff:ff, ethertype ARP
> (0x0806), length 42: Request who-has 172.21.34.10 tell 172.21.35.1,
> length 28
> 17:07:28.424208 00:0c:29:40:3a:dd > 00:a0:98:73:9f:42, ethertype ARP
> (0x0806), length 60: Reply 172.21.34.10 is-at 00:0c:29:40:3a:dd, length 4=
6
>
> The same is visable on vmnet0 nad em0 of course.
>
> Now if I replace bridge5 by vale, leaving everything else unchanged
> besides using netmap-vtnet with bhyve, I don't get ARP is-at answer.
> I can see the who-has on all interfaces involved, and also the is-at
> answer up to em0.232, but not at vtnet0 (the guest, connected via vale).
>
> To draw the same picture like with bridge:
>
> hostB --switch-- em0-hostA
>                   |
>                   '- em0.232
>                       |
>       vale232:em0.232-'
>       vale232:GUESTa--vtnet0-GUESTa <-tcpdump:
>
> 17:16:00.111868 00:a0:98:73:9f:42 > ff:ff:ff:ff:ff:ff, ethertype ARP
> (0x0806), length 42: Request who-has 172.21.34.10 tell 172.21.35.1,
> length 28
> ... no reply
>
> While tcpdump of em0.232 shows:
> 17:16:01.119537 00:a0:98:73:9f:42 > ff:ff:ff:ff:ff:ff, ethertype ARP
> (0x0806), length 60: Request who-has 172.21.34.10 tell 172.21.35.1,
> length 46
> 17:16:01.119849 00:0c:29:40:3a:dd > 00:a0:98:73:9f:42, ethertype ARP
> (0x0806), length 60: Reply 172.21.34.10 is-at 00:0c:29:40:3a:dd, length 4=
6
>
> The reply made it up to vale's uplink, but not through vale.  Am I
> missing something?
> Tagging, checksum-disabling etc. seems to be right, since utilizing
> if_bridge(4) gives the expected result, but I have no idea why I can't
> get packets via vale(4).
>
> Important note: Using em0.232 parent (vlandev em0) for vale uplink does
> work!
> So I guess if_em(4)'s native netmap support interferes with the vlan clon=
e.
> I'm out at this point, far too less knwoledge about the code paths...
> Can anybody else help here?
>
> Thanks,
>
> -harry
>



--=20
Vincenzo Maffione



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B_eA9h-L5RpNO9b4cJReQMUhhNhnUh86aMnEvx=owUM%2BTS8mA>