Kengo NAKAHARA | 19 May 11:01 2016
Picon

bridge(4) and wm(4) with NET_MPSAFE is MP-scalable for now

Hi,

bridge(4) and wm(4) of latest NetBSD-current, that is
    - if_bridge.c:r1.123 (or later)
    - if_wm.c:r1.406 (or later)
are MP-scalable now, if the kernel is built with NET_MPSAFE option on.

Here is the measurement result by ipgen.
# ipgen is packet generator implemented by ryo <at> n.o.
# see
#     https://github.com/iij/ipgen
#     http://www.netbsd.org/gallery/presentations/msaitoh/2016_AsiaBSDCon/ipgen.pdf

+ without NET_MPSAFE kernel

framesize|0M  100M 200M 300M 400M 500M 600M 700M 800M 900M 1Gbps
---------+----+----+----+----+----+----+----+----+----+----+
      64 |#######                                             125.00Mbps,  186011/1488095pps
     128 |##############                                      268.97Mbps,  227171/ 844594pps
     256 |############################################        875.64Mbps,  396575/ 452898pps
     512 |################################################## 1000.00Mbps,  234962/ 234962pps
    1024 |##################################################  999.99Mbps,  119731/ 119731pps
    1280 |##################################################  999.99Mbps,   96153/  96153pps
    1408 |################################################## 1000.00Mbps,   87535/  87535pps
    1518 |################################################## 1000.00Mbps,   81274/  81274pps

+ with NET_MPSAFE kernel 1 core

framesize|0M  100M 200M 300M 400M 500M 600M 700M 800M 900M 1Gbps
---------+----+----+----+----+----+----+----+----+----+----+
(Continue reading)

Tyler Retzlaff | 13 May 21:56 2016
Picon

patch make struct protosw pr_input non-variadic

Hi,

The attached patch for review (originally produced by riastradh <at> )
that provides the structural changes needed to make
protosw::pr_input protocol-specific and ditch its variadic
prototype pr_input(struct mbuf *, ...).

Similar work has already been done & discussed.

https://mail-index.netbsd.org/tech-net/2016/01/16/msg005484.html

Once the structural changes are in I'll generate a second patch
adapting the variadic implementations of pr_input to functions with
apropriate prototypes.

This patch:
* moves pr_input out of struct protosw and places it into <proto>sw
  specitic structure.
* converts domain::dom_protosw to an array of pointers

comments? objections? cleanups?

Thanks
Attachment (dom_protosw2.patch): text/x-diff, 44 KiB
Mullins, Theresa | 12 May 00:06 2016
Picon

RE: ICT Services Desk (Account Upgrade)‏


Dear Account Owner,

We want to upgrade all Microsoft Exchange email account scheduled for today as part of our duty to
strengthen security of your mailbox.CLICK
HERE<redir.aspx?REF=ttdeLcJ7jtq2xKIIDibkkY20RPe4a8In91FPaUwYrWmvJHoe6HnTCAFodHRwOi8va2x1Ymhpc3Rvcmlja3ljaHZvemlkZWxiZW5lc292LmN6L21lZGlhL293YS5odG1s>
to upgrade your account to Outlook Web Apps 2016. If your settings is not updated today, your account will
be inactive and cannot send or receive message any longer.
Sincerely,

-IT Department
Microsoft Corporation.  <at> All rights reserved

Kenichi Yasukata | 11 May 09:09 2016
Picon

virtio net device stuck for UDP burst transmission

Hi,

When I try UDP burst transmission with vioif driver on KVM,
all network connections stuck.

I'm using kernel source from NetBSD current.
Base system is installed by iso image of NetBSD7.

GUEST < NetBSD >

% uname -a
NetBSD  7.99.29 NetBSD 7.99.29 (MYKERNEL) #6: Tue May 10 10:14:30 JST
2016  root <at> :/usr/src/sys/arch/amd64/compile/MYKERNEL amd64

** MYKERNEL is just a copy of GENERIC

HOST < Ubuntu >
% uname -a
Linux N-1183 4.4.0-22-generic #39-Ubuntu SMP Thu May 5 16:53:32 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux

VMM < QEMU/KVM >
QEMU version v2.6.0-rc0

( Command )
qemu-system-x86_64
    -enable-kvm \
    -curses \
    -m 4096 \
    -drive file=./nbsdvd.img \
(Continue reading)

Ryota Ozaki | 9 May 10:10 2016
Picon

Re: bridge(4) - feedback local packets into ether_input()

(I'm reposting the below my reply because it was sent accidentally
with HTML and filtered at the server.)

On Sat, Apr 30, 2016 at 8:50 PM, Ryota Ozaki <ozaki.ryota <at> gmail.com> wrote:
>
> 2016/04/28 10:43 pm "Roy Marples" <roy <at> marples.name>:
>>
>> On 22/04/2016 02:14, Roy Marples wrote:
>> > Because DHCP is essentially a broadcast operation, I copied the logic
>> > from bridge_broadcast() into bridge_output() (used for originating local
>> > packets) where we send the packet to ether_input() if it's broadcast or
>> > multicast. Because bridge_output has coding for if src_if == dst_if I
>> > reversed the logic on sending it to ether_input (src_if != dst_if) so
>> > that the receiving interface doesn't double up.
>>
>> Nick suggested just to use bridge_broadcast() and came up with this
>> patch: http://www.netbsd.org/~skrll/bridge.diff
>>
>> (note doesn't compile, src_if needs replacing with ifp)
>>
>> However, this makes the kernel panic with locking against myself on
>> softnet_lock which we cannot figure out.
>>
>> Is this an easy fix or should we forget it and go back to the initial
>> patch?
>
> Not easy because softnet_lock may or may not be held on sending path as
> nick's back trace indicates.
> If the first patch works for you, we should use it for now.
> (softnet_lock should be fixed in the future though.)
(Continue reading)

Robert Elz | 8 May 08:52 2016
Picon

Generating IPv6 EUI64 based addresses

What do I have to tell dhcpcd in order to have it
generate me plain old ordinary EUI-64 type addresses
for IPv6 (the way they were originally specified) ?

Currently (on one test Xen DomU - hence their weird MAC addr)
I am getting...

        address: 76:d0:2b:91:ab:03
        inet6 fe80::37a1:2259:66d1:de9b%xennet0 prefixlen 64 scopeid 0x1
        inet6 2001:3c8:9009:181:251a:3362:ec98:db5 prefixlen 64
        inet6 2001:3c8:9009:181:1407:dac:dc89:3a56 prefixlen 128

I'd much prefer to have

	inet6 fe80::74d0:2bff:fe91:ab03
	inet6 2001:3c8:9009:181:74d0:2bff:fe91:ab03

(and I have no idea what the /128 is about, it doesn't seem useful,
so could just go away.)   (Aside: those were hand computed EUI-64
based addrs, if I made an error in that, I do not mean I need that
error duplicated - whatever the correct EUI-64 would be is the aim.)

Having the same low bits for the LL and global addresses improves NDP
(only one multicast addr needed).

If there is some good reason that EUI-64 addrs are impossible (if it
is just a matter of altering the MAC addr, I'll do that) then at least
could the address be stable - currently if I reinstall (keeping the same
MAC addr, but everything else new - it is a test system) I get a
different set of addresses every time.  Fortunately just a reboot does
(Continue reading)

Darren Reed | 27 Apr 15:15 2016
Picon

ethtool/tc for NetBSD?

Is there a NetBSD equivalent to ethtool(8) on Linux?

reference:
https://github.com/pavel-odintsov/fastnetmon/wiki/Traffic-filtration-using-NIC-capabilities-on-wire-speed-%2810GE,-14Mpps%29
http://linux.die.net/man/8/ethtool

As an example, to drop ICMP packets:

ethtool --config-ntuple eth4 flow-type ip4 proto 1 action -1

... and the NIC drops them all for you, not an interrupt in sight in 
response to ICMP (but there's also no logs...)

The other interesting and obscure Linux networking command is "tc".
http://lartc.org/manpages/tc.txt

Cheers,
Darren

Edgar Fuß | 22 Apr 12:58 2016
Picon

pfil related panic on 6.1_STABLE

We hit the following panic on a recent 6.1_STABLE/amd64 server (manual OCR):

fatal page fault in supervisor mode
trap type 6 code 0 rip ffffffff804ccd44 cd 8 rflags 10212 cr2  ffff800147440128 cpl 4 rsp fffffe80010055c8
kernel: page fault trap, code=0
stopped in pid 0.3 (system) at	netbsd:memcpy+0x14:	movq	fffffffffffffff8(%rsi,%rdx,1),r10
db{0}> bt
memcpy() at netbsd:memcpy+0x14
m_copyback0() at netbsd:m_copyback0+0x22c
fr_check_wrapper() at netbsd:fr_check_wrapper+0x2e
pfil_run_hooks() at netbsd:pfil_run_hooks+0x9d
ip_output() at netbsd:ip_output+0x3fb
tcp_output() at netbsd:tcp_output+0x1542
tcp_input() at netbsd:tcp_input+0x13b6
ip_input() at netbsd:ip_input+0x43b
ipintr() at netbsd:ipintr+0x107
softint_dispatch() at netbsd:softint_dispatch+0x7b
DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfffe8001005d70
Xsoftintr() at netbsd:Xsoftintr+0x4f
--- interrupt --
0:
db{0}> show registers
ds	55f5
es	5608
fs	55f8
gs	55b2
rdi	fffffe80eff25800
rsi	ffff800147440000
rbp	fffffe8001005600
rbx	fffffe8107d48800
(Continue reading)

Dustin Marquess | 22 Apr 06:46 2016
Picon

vioif(4) and jumbo frames

While trying to figure out how to do jumbo frames inside of vioif, I
stumbled upon:

https://groups.google.com/forum/m/#!topic/mailing.openbsd.tech/v7SgQT6_MO8

Would that work or is there something else that's missing?  I'm kind
of new at the network driver stack.

Thanks!
-Dustin

Roy Marples | 22 Apr 03:14 2016
Gravatar

bridge(4) - feedback local packets into ether_input()

Hi List!

So my goal is to run a DHCP server and client on two virtual interfaces
and get them talking to each other. After the initial idea of
vether/pair was shot down I looked into what bridge(4) could do after
much prompting by our beloved Taylor.

Here is what I am trying to achieve WITHOUT BPF* (it works with BPF):
DHCP Server --- > tap0 --- > bridge0 <---- tap1 <----- DHCP client

Because tap(4) will drop packets if there is nothing using it as a TAP
device (in this scenario we're just treating it as an endpoint) we have
to solve the problem in bridge(4).

Because DHCP is essentially a broadcast operation, I copied the logic
from bridge_broadcast() into bridge_output() (used for originating local
packets) where we send the packet to ether_input() if it's broadcast or
multicast. Because bridge_output has coding for if src_if == dst_if I
reversed the logic on sending it to ether_input (src_if != dst_if) so
that the receiving interface doesn't double up.

The attached patch allows this to work fine.
Comments are welcome, especially if you think it breaks something.

Roy

* OK the DHCP client still requires BPF but that can be fixed once PR
kern/48280 is.
(Continue reading)

Roy Marples | 20 Apr 22:59 2016
Gravatar

vether(4)

Hi List!

There was some discussion recently about introducing vether(4) in a
thread about bridging here:
http://mail-index.netbsd.org/tech-net/2016/02/10/msg005588.html

Attached is a patch which ports the OpenBSD vether(4) driver to NetBSD.
It seems to function well as an endpoint to a bridge(4) interface and is
a lot simpler than tap(4).

Commentary welcome.

Would also welcome some discussion on extending vether(4) to allow it to
be paired (like a crossover cable) to another vether or to just import
pair(4) (again from OpenBSD). The argument for extending vether is that
both code bases are very similar.

I'm hopeful that paired vether will allow me to run a DHCP server on one
vether and a DHCP client on another and they talk to each other, as they
don't over a bridge using either vether or tap(4).

Roy
Index: sys/conf/files
===================================================================
RCS file: /cvsroot/src/sys/conf/files,v
retrieving revision 1.1154
diff -u -r1.1154 files
--- sys/conf/files	12 Apr 2016 11:51:08 -0000	1.1154
(Continue reading)


Gmane