Re: vale-ctl(-8), ifconfig(8), SIOCAIFADDR: Invalid argument [utilizing netmap(4) providing virtual switches+interfaces to BHyVe]

2016-10-15 Thread Vincenzo Maffione 
2016-10-14 15:38 GMT+02:00 Harry Schmalzbauer :

> Bezüglich Vincenzo Maffione's Nachricht vom 14.10.2016 15:08 (localtime):
> > Hi,
> >
> >   Thanks for your feedback.
> >
> …
> >> Accidentally I found out that 'vale-ctl -n testif0' creates a artificial
> >> interface, which is reported by ifconfig(8):
> >> testif0: flags=8801 metric 0 mtu 1500
> >> options=8
> >> ether 00:be:eb:8d:f8:00
> >> nd6 options=21
> >>
> >> But I can't assign a IP address: 'ifconfig testif0 203.0.113.1/24'
> >> ifconfig: ioctl (SIOCAIFADDR): Invalid argument
> >>
> >> I guess couldn't geti the picture of the netmap(4) world yet.
> >> Probably, testif0 is available only in netmap(4) world, not in "host
> >> world".
> >> I'm assuming, because I found vale-ctl(-8)s "-h" switch.
> >>
> >
> > Yes, those are the "persistent" VALE ports. They are a recent feature,
> and
> > probably you don't need to use them if you are going to play with Virtual
> > Machines and jails (see below).
>
> Hello Vincenzo,
>
> thank you very much for your help!!!
>
>
> …
> >> Now my question:
> >>
> >> How can I plug a jail's or vmm's artificial interface to a VALE virtual
> >> switch, bridging frames to real-world via physical interfaces?
> >> (the latter part should work with vale-ctl -h vale0:em1, but what
> >> interface to use for jail(8) vnet.interface and how to create/attach?)
> >>
> >
> > If you use bhyve/vmm, you can attach the VM TAP interface to the VALE
> > switch, as you would do for "em1". Regarding jails, I don't know exactly
> > how networking works there, but I guess epair(4) interface (or similar)
> are
> > used. If this is the case, then you would have one end of the epair only
> > visible in the jail, and the other end only visible in the "host"; then
> you
>
> I'm familar with epair(4), but not with tap(4).
> I don't understand the man page for tap, perhaps I should read pty(4)…
> But I guess I don't have to know the details of tap(4), since you
> confirmed that it can be connected to VALE.
>

It's not necessary to understand the details. However, a TAP device is
conceptually similar to the two ends of an epair, with the difference that
in the TAP a network interface (e.g. tap0) is conecptually "connected"
back-to-back to a file descriptor. The file descriptor is written/read by
the hypervisor (to inject/intercept packets to/from the network stack),
while the tap0 interface can be attached to if_bridge.


>
> So one could summarize:
> VALE (as part of netmap(4)) can act as a if_bridge(4) replacement in
> FreeBSD-10/11, keeping everything else involved untouched.
> Please correct me if I'm wrong.
>

For simple cases yes. if_bridge may have features that are not supported by
netmap (i.e. configure ports as VLAN access ports). Moreover, if_bridge has
a interface (br0), whereas VALE bridges doesn't.

>
>
> > could attach the host end to a VALE switch again with "vale-ctl -a".
> > Unfortunately, the performance you would get in any case is not great,
> > because TAP and epair interface do not have netmap "native support".
> > Moreover, when using bhyve, you have to pay the cost of the emulation of
> > the vtnet device, since each packet passes through this device (other
> than
> > passing across netmap).
>
> I understand, thanks.
> In fact, I expected that at first hand, but have had some oddities with
> if_bridge(4) some years ago, so I thought I'd better try something new ;-)
> Can I expect any resource savings over if_bridge(4)? I guess if so, the
> ammount isn't relevant considering the whole bhyve scenarium.
>

I don't think you can expect resource savings in terms of memory, since
netmap is trading off memory for performance, using pre-allocation rather
than dynamic allocation (of each packet).
I don't know what happens in terms of CPU saving, but using TAPs, epair and
vtnet makes the system as a whole not really efficient (as if_bridge), so
you may end up with nothing.


>
>
> > However, consider the following: a consistent netmap update is going to
> > happen in FreeBSD-CURRENT, in short. This is going to align the netmap
> code
> > which is now in FreeBSD to the code on the official github repository (
> > https://github.com/luigirizzo/netmap). Among the new features, there is
> a
> > new solution for bhyve networking, which will let you attach your bhyve
> VMs
> > directly to a VALE switch, without paying additional overheads related to
> > TAPs, epairs, and vtnet emulation. You can find additional information,
> > code and performance numbers here:
> > https://wiki.freebsd.org/SummerOfCode2016/PtnetDriverAndDeviceModel.
>
> Thanks for that hint!
> I guess it's about ptnetmap(4)? I read papers but haven't considered it
> could be production-ready for FreeBSD in the near future.
> It's extremely interesting and I'd love to be eraly adopter, but my
> (ESXi) setups are currently doing well and I don't have spare time or
> any business project to try out… :-(
>

Yes, it's ptnetmap. However, bhyve is going to have support for VALE p

Re: aibs(4) / atk0110 support for newer systems

2016-10-15 Thread Andriy Gapon 
On 14/10/2016 21:49, Torfinn Ingolfsen wrote:
> On Tue, 11 Oct 2016 14:29:34 +0300
> Andriy Gapon  wrote:
> 
>> On 06/10/2016 00:37, Andriy Gapon wrote:
>>> On 05/10/2016 23:28, Torfinn Ingolfsen wrote:
 #6  0x80cd0081 in calltrap ()
 at /usr/src/sys/amd64/amd64/exception.S:238
 #7  0x81bcb078 in aibs_add_sensor () from /boot/kernel/aibs.ko
 #8  0x81bcb4b4 in aibs_attach_sif () from /boot/kernel/aibs.ko
>>>
>>> Argh, I've just spotted a very silly typo.
>>> Could you please replace '0' with 'o' in
>>> err = aibs_add_sensor(sc, 0, &as[i], &descr);
>>> ?
>>
>> Ping.
> 
> Done - see other messages in this thread. Sorry about the delay.
> 

No worries.  Thank you very much for your testing!
I've just committed the change to head.

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: vale-ctl(-8), ifconfig(8), SIOCAIFADDR: Invalid argument [utilizing netmap(4) providing virtual switches+interfaces to BHyVe]

2016-10-15 Thread Harry Schmalzbauer 
Bezüglich Vincenzo Maffione's Nachricht vom 15.10.2016 09:32 (localtime):
> 2016-10-14 15:38 GMT+02:00 Harry Schmalzbauer :

…
>> I'm familar with epair(4), but not with tap(4).
>> I don't understand the man page for tap, perhaps I should read pty(4)…
>> But I guess I don't have to know the details of tap(4), since you
>> confirmed that it can be connected to VALE.
>>
> 
> It's not necessary to understand the details. However, a TAP device is
> conceptually similar to the two ends of an epair, with the difference that
> in the TAP a network interface (e.g. tap0) is conecptually "connected"
> back-to-back to a file descriptor. The file descriptor is written/read by
> the hypervisor (to inject/intercept packets to/from the network stack),
> while the tap0 interface can be attached to if_bridge.

Hi Vincenzo, thanks for your explanation!


>>
>> So one could summarize:
>> VALE (as part of netmap(4)) can act as a if_bridge(4) replacement in
>> FreeBSD-10/11, keeping everything else involved untouched.
>> Please correct me if I'm wrong.
>>
> 
> For simple cases yes. if_bridge may have features that are not supported by
> netmap (i.e. configure ports as VLAN access ports). Moreover, if_bridge has
> a interface (br0), whereas VALE bridges doesn't.

Again, thank you for your time! (R)STP comes to my mind (which I don't
need any more). And I'm not sure if VALE really lacks that, but I guess
it wouldn't match VALEs philosophy/design at all…

…
>>> https://github.com/luigirizzo/netmap). Among the new features, there is
>> a
>>> new solution for bhyve networking, which will let you attach your bhyve
>> VMs
>>> directly to a VALE switch, without paying additional overheads related to
>>> TAPs, epairs, and vtnet emulation. You can find additional information,
>>> code and performance numbers here:
>>> https://wiki.freebsd.org/SummerOfCode2016/PtnetDriverAndDeviceModel.
>>
>> Thanks for that hint!
>> I guess it's about ptnetmap(4)? I read papers but haven't considered it
>> could be production-ready for FreeBSD in the near future.
>> It's extremely interesting and I'd love to be eraly adopter, but my
>> (ESXi) setups are currently doing well and I don't have spare time or
>> any business project to try out… :-(
>>
> 
> Yes, it's ptnetmap. However, bhyve is going to have support for VALE ports
> anyway (even without ptnetmap), as QEMU already does, so at least you will
> be able to replace TAPs with VALE ports (while still using vtnet devices
> for the VM).

Oic, I wasn't aware that there will be a VALE-vtnet direct path! That is
really great news :-) And a big achievment for guests preferring
"standard" drivers, ptnetmap could limit the guest OS choice I guess.

For now, I'm happy having been in touch with netmap(4) – at least with a
very little fraction of natmap – but I'll stay the legacy way utilizing
if_bridge(4) and see if there are still oddities and try to find some
time to track them down (involving LACP, VLANs, Jumbo-Frames and IPv6 –
that was the problematic constellation)

Since I have extra PHYs, I can do PCIe-passthrough like before (with
ESXi) for some special guests. I'm looking forward to find out how this
works with bhyve!

Best,

-Harry
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Errata notice for 11.0 -- question

2016-10-15 Thread Karl Denninger 
I noted this /after /svn updating my 11.x box to the most-current -STABLE:

A bug was diagnosed in interaction of the |pmap_activate()| function
and TLB shootdownIPI handler on amd64 systems which
have PCID features but do not implement theINVPCID instruction. On
such machines, such as SandyBridge™ and IvyBridge™
microarchitectures, set the loader
tunable |vm.pmap.pcid_enabled=0| during boot:

set vm.pmap.pcid_enabled=0
boot

Add this line to |/boot/loader.conf| for the change to persist
across reboots:

To check if the system is affected, check dmesg(8)


 for PCID listed
in the "Features2", and absence of INVPCID in the "Structured
Extended Features". If the PCID feature is not present,
or INVPCID is present, system is not affected.

Well, I'm allegedly subject to this:

Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-STABLE #13 r307318M: Fri Oct 14 09:23:46 CDT 2016
k...@newfs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP amd64
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on
LLVM 3.8.0)
VT(vga): text 80x25
CPU: Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz (2400.13-MHz
K8-class CPU)
  Origin="GenuineIntel"  Id=0x206c2  Family=0x6  Model=0x2c  Stepping=2
 
Features=0xbfebfbff
 
Features2=0x29ee3ff
  AMD Features=0x2c100800
  AMD Features2=0x1
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics

And I do _*not*_ have it turned off at this moment.

vm.pmap.invpcid_works: 0
vm.pmap.pcid_enabled: 1

But I've also yet to see any sort of misbehavior.

So the questions are:

1. What's the misbehavior I should expect to see if this is not shut off
(and it isn't)?

2. Should I take this machine down immediately to reboot it with
vm.pmap.pcid_enabled=0 in /boot/loader.conf?

A svn log perusal didn't see anything post the errata date that appears
to be related which makes me wonder.

Thanks in advance!

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature