headers
Wayne Marsh | 14 Jun 2013 06:27
Picon

X520-DA2 10Gbps

 Hello all,

 I'm working on getting a NetBSD box working with an X520-DA2 card at 10Gbps.

 I've enabled Jumbo Frames up to mtu 8982 and this seemed to give us a gain
 of 500Mbps as compared to a 1500 mtu.

 The best we can get with this card is 2.9Gbps. using iperf with 8982 mtu
 and 2.4Gbps with 1500 mtu.

 Any ideas?

Wayne
Permalink | Reply | 3 comments |
headers
Mark Davies | 13 Jun 2013 03:30
Picon
Picon

wm MDIC write error

Hi,
   I have a 6.0_STABLE/i386 (almost 6.1) box with an onboard PCH2 LAN 
82579LM (wm0) and an Intel i82574L on a PCIe card (wm1)

When I first boot the machine both network ports work fine but after a 
while wm1 stops and I get lots of the following logged:

          [...]
wm1: MDIC write error: phy 1 reg 0
wm1: MDIC write error: phy 1 reg 4
wm1: MDIC write error: phy 1 reg 9
wm1: MDIC write error: phy 1 reg 0
          [...]

Need to powercycle the machine to get it working again.

Anybody know whats broken here?  Have a fix? (in current?)

cheers
mark
Permalink | Reply | 3 comments |
headers
David Young | 12 Jun 2013 04:50
Picon
Favicon

ifconfig v2

I was just reminded what improvements can be made to ifconfig output
when I read this ifconfig output that appeared on current-users today:

wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        capabilities=7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
        capabilities=7ff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
        capabilities=7ff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
        enabled=0
        ec_capabilities=7<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU>
        ec_enabled=0
        address: 00:26:2d:f3:c8:c7
        media: Ethernet none (none)
        inet 169.254.162.222 netmask 0xffff0000 broadcast 169.254.255.255
        inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1

The ALL-CAPITALS text is really hard to read.  Let's change that to
lower:

wm0: flags=8843<up,broadcast,running,simplex,multicast> mtu 1500
        capabilities=7ff80<tso4,ip4csum_rx,ip4csum_tx,tcp4csum_rx>
        capabilities=7ff80<tcp4csum_tx,udp4csum_rx,udp4csum_tx,tcp6csum_rx>
        capabilities=7ff80<tcp6csum_tx,udp6csum_rx,udp6csum_tx,tso6>
        enabled=0
        ec_capabilities=7<vlan_mtu,vlan_hwtagging,jumbo_mtu>
        ec_enabled=0
        address: 00:26:2d:f3:c8:c7
        media: Ethernet none (none)
        inet 169.254.162.222 netmask 0xffff0000 broadcast 169.254.255.255
        inet6 fe80::226:2dff:fef3:c8c7%wm0 prefixlen 64 scopeid 0x1
(Continue reading)

Permalink | Reply | 44 comments |
headers
David G. | 11 Jun 2013 09:02

Slow Gigabit Ethernet

Hi,

I recently installed NetBSD 6.1 and while the installation was easy and
the RTL8169SC Ethernet adapter was recognized, I seem to be getting
sluggish performance.  I'm only seeing around 25-30% of the usage.  In
the past, I was easily able to get 50% or higher.

Any ideas?

Thanks!

NIC info:

nbsd# ifconfig re1
re1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        capabilities=3f80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx>
        enabled=0
        address: 00:14:d1:22:d3:08
        media: Ethernet autoselect (1000baseT full-duplex)
        status: active
        inet 10.1.1.10 netmask 0xffffff00 broadcast 10.1.1.255
        inet6 fe80::214:d1ff:fe22:d302%re1 prefixlen 64 scopeid 0x2

--

-- 
http://www.fastmail.fm - Send your email first class
Permalink | Reply | 1 comment |
headers
Mark Keaton | 10 Jun 2013 20:13
Picon

Locking question

I am trying to understand the locking strategy used in the following 
functions on NetBSD 6:

   ip_input()
   ip_output()
   ip6_input()
   ip6_output()
   ip6_forward()

There are several cases where these functions are called with the 
"softnet_lock" mutex locked, and I assumed that this would always be true.

However, I added a KASSERT(mutex_owned(softnet_lock)) call to these 
functions, ran a test, and found that there is at least one case where 
this assertion fails.  Here is the call chain that caused the failure:

   ip6_output()
   mld_sendpkt()
   mld_start_listening()
   in6_addmulti()
   in6_joingroup()
   in6_update_ifa1()
   in6_update_ifa()
   in6_control1()
   in6_control()
   udp6_usrreq_wrapper()
   compat_ifioctl()
   ifioctl()
   soo_ioctl()
   sys_ioctl()
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mindaugas Rasiukevicius | 9 Jun 2013 03:19
Picon

Mandatory PFIL_HOOKS

Hi,

Unless anyone objects, I would like to make packet filter hooks mandatory
and therefore remove PFIL_HOOKS option.  They are small, often used and not
worth the #ifdef mess.

Thanks.

--

-- 
Mindaugas
Permalink | Reply | 5 comments |
headers
Roy Marples | 31 May 2013 20:17
Favicon
Gravatar

dhcpcd DHCPv6 Prefix Delegation - help making a prefix

Hi List

dhcpcd (in my git tree) supports DHCPv6 Prefix Delegation and has done 
for a while now.
It's undergone extensive testing and I feel that it's ready aside from 
one issue - configuration.

Currently we get a prefix delegated and we don't know it's length in 
advance.
Realistically it will be from /48 to /64.

Here are some examples:
3FFE:FFFF:5::/48
3FFE:1234:5678:fc::/62

This is a problem as the user is expected to supply an SLA and length 
to match the delegated prefix and generate a /64.
Also, this has to be divisble by 8 with my current code (i think).

So assuming we have a unique number per interface how can we generate a 
/64 for each interface and prefix automatically so that all the user as 
to do is request a PD and optionally interfaces to apply it to?

Thanks

Roy
Permalink | Reply | 0 comments |
headers
Roy Marples | 30 May 2013 15:02
Favicon
Gravatar

PATCH to mark IPv6 addresses DETACHED when down or link down

Hi List!

When a link status reports no carrier, or an interface is brought down 
the state of all IPv6 addresses remains the same.
This means that when carrier is up or the interface is brought up no 
duplicate address checking is performed.

We currently have the rather unused IN6_IFF_DETACHED flag and the 
attached patch sets this when the interface is brought down or carrier 
lost.
When it's brought up again with a carrier, the detached flag is 
cleared, the tentative flag is set and DAD starts.
The routing socket is notified of all relevant changes via a 
RTM_NEWADDR message.

dhcpcd can now listen to this and knows that it can start dealing with 
IPv6 foo once the interface is up AND the locallink address is ready to 
be used.
A nice side effect of this is that dhcpcd (latest git code) can now 
manipulate the routing table to prefer one interface over another on the 
same network
and a ping6 command to the server works seamlessly while the wired and 
wireless interfaces are toggled up/down.

Comments welcome.

Thanks

Roy
Attachment (ipv6-down-tentative.diff): text/x-diff, 5323 bytes
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roy Marples | 15 May 2013 10:24
Favicon
Gravatar

PATCH to only announce RTM_NEWADDR once IPv6 DAD completes

Hi List

Old discussion references:
http://mail-index4.netbsd.org/tech-net/2012/10/19/msg003676.html
http://mail-index.netbsd.org/current-users/2010/05/12/msg013334.html
http://mail-index.netbsd.org/current-users/2010/05/25/msg013529.html
http://mail-index.netbsd.org/tech-net/2010/05/25/msg002094.html

I agree with the latest proposal and attach a patch for review to 
address it.
I've been testing this with a new dhcpcd build which listens for 
RTM_NEWADDR or a duplicate NA message and reacts accordingly.
This is important as not only daemons fail to bind with a tentative 
address from a RTM_NEWADDR message, but one shot things normally run 
after successful address configuration, such as ntpdate also fail.

Although dhcpcd does have it's own DAD engine, it's not RFC 
conformation (no kernel allows it to be), so getting kernels to 
correctly announce RTM_NEWADDR when the address is ready does at least 
allow userland applications such as dhcpcd to take advantage of the 
kernel DAD.

Comments are welcome, probably comitting it over the weekend with 
hopefully a new dhcpcd shortly afterwards.

Thanks

Roy
Attachment (ipv6-tentative.diff): text/x-diff, 4555 bytes
Permalink | Reply | 8 comments |
headers
Edgar Fuß | 18 Apr 2013 15:05
Picon
Favicon

net.inet6.ip6.v6only

I have some questions on net.inet6.ip6.v6only.

First: What does it mean, exactly?
My best guess is "a socket created with a domain argument of PF_INET6 will not
conect() to a RFC 3493 v6-mapped v4 address".

Second: What's the rationale behind the default being 1?

Third: What's the drawback (or what are the security implications) of setting
the knob to 0, i.e. enabling mapped addresses? My impression is that neither
squid nor lighttpd will, on a host with non-local v6 adresses, work correctly
without because they (on a v6 host) will only create PF_INET6 sockets and then
try to connect to v6-mapped v4 adresses.
Permalink | Reply | 4 comments |
headers
Beverly Schwartz | 17 Apr 2013 00:55
Picon

Seeking opinion on where networking-related user space code should go

I have created a facility in the kernel for tracking mbuf clusters.  (Twice at BBN, we have successfully used
this cluster tracking code to find mbuf cluster leaks.)

This facility can be compiled in the kernel by enabling the option MCL_DEBUG.

If MCL_DEBUG is enabled, then tracking data is kept for each mbuf cluster.  Examples of data kept:
When and where in the code the cluster was allocated.
When and where in the code the cluster was freed.
When and where the cluster was queued or dequeued.
When and where the cluster was passed from one protocol to another.

At each of these points, I note which CPU we're on, the LWP id, whether or not we have KERNEL_LOCK and/or
softnet lock, if there was something anomalous.  Anomalies detected: cluster allocated twice without
being freed in-between, cluster freed without being allocated, cluster unallocated when expected to be
allocated, lock not held when expected to be held.

I have set up code in /proc for accessing the data, but it would be nice to have a user space program to look at
the data.  Using kvm, this data can be inspected in a live kernel or in a core dump.

Keep in mind, there can be up to 8192 clusters, so there is potentially a *lot* of data.  Using kvm, we can also
follow pointers in the data to inspect the contents of mbuf's and mbuf clusters.  I expect that this, too,
could be quite useful.

Options I have considered:
- a new usr.bin program
- adding new options to vmstat for this data
- adding new options to netstat for this data

Any thoughts or preferences?
(Continue reading)

Permalink | Reply | 4 comments |

Gmane