Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Jan 2019 20:59:41 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 235031] [em] em0: poor NFS performance, strange behavior
Message-ID:  <bug-235031-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235031

            Bug ID: 235031
           Summary: [em] em0: poor NFS performance, strange behavior
           Product: Base System
           Version: 12.0-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: d8zNeCFG@aon.at

Scenario
=3D=3D=3D=3D=3D=3D=3D=3D
I have a laptop with the following for em0 in /var/run/dmesg.boot:

em0: <Intel(R) PRO/1000 Network Connection> port 0x6040-0x605f mem
0xd5300000-0xd531ffff,0xd532b000-0xd532bfff irq 20 at device 25.0 on pci0
em0: attach_pre capping queues at 1
em0: using 1024 tx descriptors and 1024 rx descriptors
em0: msix_init qsets capped at 1
em0: Unable to map MSIX table=20
em0: Using an MSI interrupt
em0: allocated for 1 tx_queues
em0: allocated for 1 rx_queues

[0]# ifconfig em0
em0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
=20=20=20=20=20=20=20
options=3D81249b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LRO,WOL_=
MAGIC,VLAN_HWFILTER>
        ether f0:de:f1:98:86:a9
        inet 192.168.1.19 netmask 0xffffff00 broadcast 192.168.1.255=20
        inet6 fe80::f2de:f1ff:fe98:86a9%em0 prefixlen 64 scopeid 0x1=20
        inet6 fec0:0:0:4d42::13 prefixlen 64=20
        inet6 fec0::4d42:f2de:f1ff:fe98:86a9 prefixlen 64 autoconf=20
        inet6 2002:5875:4c34:4d42:f2de:f1ff:fe98:86a9 prefixlen 64 autoconf=
=20
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=3D23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
[0]#=20

This laptop exports a filesystem via NFS to a second machine running a 100 =
Mbit
interface.

The second machine performs read requests via NFS.

Result
=3D=3D=3D=3D=3D=3D
The result is that the NFS performance is very poor, on the order of 500 kB=
ps
to 1 MBps (5..10% of the 100 Mbps of the second machine).

Scenario (continued)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
There is a third machine with a gigabit interface.

Result
=3D=3D=3D=3D=3D=3D
If I run iperf between the laptop and the third machine, the read performan=
ce
for the second machine increases (!) to several MB/s (20..40% of the 100 Mb=
ps
of the second machine). The iperf performance itself is close to wire speed
(914 Mbps).

Note
=3D=3D=3D=3D
Maybe this problem is the one which underlies the issue I reported in bug
#234520; machine B in that scenario is the laptop, machine A is the third
machine.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235031-227>