[Bug 230996] em/igb: Intel i210/i350: ifconfig: enabling "vlanhwtag" renders VLAN on i210/i350 NICs unusable
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230996 --- Comment #28 from Kaho Toshikazu --- Created attachment 224588 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=224588&action=edit iflib-vlan patch It contains a correction of iflib side with debug code, and it does not conflicts other patch. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238411] igb(4): Wake on Lan not working with Intel I210
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238411 --- Comment #21 from Kaho Toshikazu --- (In reply to Abraham122x from comment #20) FreeBSD 12 and 13 have almost same code but 11 has difference. I think that wol capability is not set with these type devices on FreeBSD 11, then you can not toggle enable/disable wol by using ifconfig. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPsec performace - netisr hits %100
I've pulled the latest stable/13 branch and make buildworld.
Same configuration and same usage, ping works between two sides, iperf can
connect to server but no data transferred. throughput is around 10Kbps.
I tried both with and without netipsec/ipsec_input.c patch, but no change.
There is something wrong with ipsec (or ipsec in jail) in stable/13.
iperf between host and jail works without ipsec.
I saw some errors in truss output show as a brief:
write(3,"@\^A\0x\0\0\0\^A\0\0\^S\M^I\0\0"...,131072) ERR#35 'Resource
temporarily unavailable'
recvfrom(3,0x8018048c0,131072,0,0x0,0x0) ERR#35 'Resource temporarily
unavailable'
_umtx_op(0x80026e008,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffdfffdec8)
ERR#60 'Operation timed out'
Full output of truss output is below:
root@host # jexec client bash
[root@client /]# truss iperf -B 172.16.70.1 -c 172.16.68.1 2>&1 | grep -v
clock_nanosleep
mmap(0x0,135168,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34362150912 (0x80024d000)
mprotect(0x80024a000,4096,PROT_READ) = 0 (0x0)
issetugid() = 0 (0x0)
sigfastblock(0x1,0x80024c510) = 0 (0x0)
open("/etc/libmap.conf",O_RDONLY|O_CLOEXEC,011136710) = 3 (0x3)
fstat(3,{ mode=-rw-r--r-- ,inode=482,size=47,blksize=4096 }) = 0 (0x0)
read(3,"# $FreeBSD$\nincludedir /usr/loc"...,47) = 47 (0x2f)
close(3) = 0 (0x0)
open("/usr/local/etc/libmap.d",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0165)
ERR#2 'No such file or directory'
open("/var/run/ld-elf.so.hints",O_RDONLY|O_CLOEXEC,010015464) = 3 (0x3)
read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\M-U\0\0"...,128) = 128 (0x80)
fstat(3,{ mode=-r--r--r-- ,inode=187,size=341,blksize=4096 }) = 0 (0x0)
pread(3,"/lib:/usr/lib:/usr/local/lib:/us"...,213,0x80) = 213 (0xd5)
close(3) = 0 (0x0)
open("/lib/libthr.so.3",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=186701,size=125952,blksize=32768 }) = 0
(0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,3,0x0) = 34362286080
(0x80026e000)
mmap(0x0,184320,PROT_NONE,MAP_GUARD,-1,0x0) = 34362290176 (0x80026f000)
mmap(0x80026f000,53248,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x0)
= 34362290176 (0x80026f000)
mmap(0x80027c000,73728,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0xc000)
= 34362343424 (0x80027c000)
mmap(0x80028e000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x1d000)
= 34362417152 (0x80028e000)
mmap(0x80028f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x1d000)
= 34362421248 (0x80028f000)
mmap(0x800291000,45056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0)
= 34362429440 (0x800291000)
munmap(0x80026e000,4096) = 0 (0x0)
close(3) = 0 (0x0)
open("/lib/librt.so.1",O_RDONLY|O_CLOEXEC|O_VERIFY,066000) ERR#2 'No such
file or directory'
open("/usr/lib/librt.so.1",O_RDONLY|O_CLOEXEC|O_VERIFY,066000) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=411606,size=22824,blksize=32768 }) = 0
(0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,3,0x0) = 34362286080
(0x80026e000)
mmap(0x0,36864,PROT_NONE,MAP_GUARD,-1,0x0) = 34362474496 (0x80029c000)
mmap(0x80029c000,12288,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x0)
= 34362474496 (0x80029c000)
mmap(0x80029f000,12288,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x2000)
= 34362486784 (0x80029f000)
mmap(0x8002a2000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x4000)
= 34362499072 (0x8002a2000)
mmap(0x8002a3000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x4000)
= 34362503168 (0x8002a3000)
mmap(0x8002a4000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0)
= 34362507264 (0x8002a4000)
munmap(0x80026e000,4096) = 0 (0x0)
close(3) = 0 (0x0)
open("/lib/libc++.so.1",O_RDONLY|O_CLOEXEC|O_VERIFY,00) ERR#2 'No such file
or directory'
open("/usr/lib/libc++.so.1",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=411469,size=824056,blksize=32768 }) = 0
(0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,3,0x0) = 34362286080
(0x80026e000)
mmap(0x0,860160,PROT_NONE,MAP_GUARD,-1,0x0) = 34362511360 (0x8002a5000)
mmap(0x8002a5000,376832,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x0)
= 34362511360 (0x8002a5000)
mmap(0x800301000,425984,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x5b000)
= 34362888192 (0x800301000)
mmap(0x800369000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0xc2000)
= 34363314176 (0x800369000)
mmap(0x80036f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0xc7000)
= 34363338752 (0x80036f000)
mmap(0x800371000,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0)
= 34363346944 (0x800371000)
munmap(0x80026e000,4096) = 0 (0x0)
close(3) = 0 (0x0)
open("/lib/libcxxrt.so.1",O_RDONLY|O_CLOEXEC|O_VERIFY,041400) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=186668,size=113688,blksize=32768 }) = 0
(0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MA
Re: IPsec performace - netisr hits %100
This bug is related to CCR. @Navdeep Parhar , @John Baldwin
if you are interested to fix this bug related with CCR, I
can test if you provide patches. Test environment is explained in my first
email on this thread.
@Mark Johnston Now again on stable/13,
- with aesni, without netipsec/ipsec_input.c patch - 1.44Gbps - single
netisr thread eats %100 cpu
- with qat, without netipsec/ipsec_input.c patch - 1.88Gbps - single netisr
thread eats %100 cpu
- with aesni, with netipsec/ipsec_input.c patch - 1.33Gbps
PID JID USERNAMEPRI NICE SIZERES STATEC TIMEWCPU
COMMAND
7 0 root-16- 0B16K CPU4 4 0:39 98.62%
[crypto returns 3]
6 0 root-16- 0B16K CPU5 5 0:32 84.14%
[crypto returns 2]
11 0 root-92- 0B 1152K CPU8 8 0:28 72.17%
[intr{irq97: t6nex0:0a2}]
11 0 root-92- 0B 1152K CPU3 3 0:20 51.22%
[intr{irq107: t6nex0:1a2}]
8 0 root-16- 0B16K crypto 7 0:12 30.68%
[crypto returns 4]
0 0 root-20- 0B13M RUN 7 0:07 21.52%
[kernel{crypto_2}]
0 0 root-20- 0B13M CPU12 12 0:06 20.53%
[kernel{crypto_15}]
0 0 root-20- 0B13M CPU9 9 0:05 19.97%
[kernel{crypto_0}]
0 0 root-20- 0B13M -0 0:05 19.86%
[kernel{crypto_14}]
5 0 root-16- 0B16K CPU2 2 0:08 19.75%
[crypto returns 1]
0 0 root-20- 0B13M -6 0:05 19.56%
[kernel{crypto_9}]
0 0 root-20- 0B13M -7 0:07 18.74%
[kernel{crypto_3}]
0 0 root-20- 0B13M - 13 0:07 18.68%
[kernel{crypto_5}]
0 0 root-20- 0B13M CPU1 1 0:07 18.12%
[kernel{crypto_11}]
0 0 root-20- 0B13M -2 0:07 17.46%
[kernel{crypto_8}]
0 0 root-20- 0B13M CPU10 10 0:05 17.31%
[kernel{crypto_1}]
0 0 root-20- 0B13M -4 0:06 17.08%
[kernel{crypto_7}]
0 0 root-20- 0B13M - 14 0:07 16.07%
[kernel{crypto_12}]
0 0 root-20- 0B13M - 11 0:07 15.39%
[kernel{crypto_6}]
0 0 root-20- 0B13M -6 0:07 12.09%
[kernel{crypto_4}]
- with qat, with netipsec/ipsec_input.c patch - 2.85Gbps -
PID JID USERNAMEPRI NICE SIZERES STATEC TIMEWCPU
COMMAND
20 0 root-16- 0B16K CPU6 6 0:18 89.69%
[crypto returns 13]
19 0 root-16- 0B16K CPU4 4 0:17 80.25%
[crypto returns 12]
11 0 root-92- 0B 1696K CPU1 1 0:52 43.90%
[intr{irq97: t6nex0:0a2}]
21 0 root-16- 0B16K crypto 0 0:09 43.43%
[crypto returns 14]
18 0 root-16- 0B16K crypto 2 0:05 24.94%
[crypto returns 11]
11 0 root-92- 0B 1696K WAIT12 0:35 20.18%
[intr{irq107: t6nex0:1a2}]
11 0 root-92- 0B 1696K WAIT 8 0:02 7.44%
[intr{irq168: qat1}]
4202 1 root 23032M 4480K sbwait 14 0:01 5.57%
iperf -B 172.16.70.5 -c 172.16.68.1 -P 2 -t 30{iperf}
4217 1 root 22032M 4480K sbwait 5 0:01 5.52%
iperf -B 172.16.70.10 -c 172.16.68.1 -P 2 -t 30{iperf}
...
11 0 root-92- 0B 1696K WAIT12 0:01 4.39%
[intr{irq155: qat0}]
4182 0 root 210 105M40M sbwait 4 0:01 4.04%
iperf -s{iperf}
4182 0 root 210 105M40M sbwait 5 0:01 3.99%
iperf -s{iperf}
...
11 0 root-92- 0B 1696K WAIT12 0:00 1.84%
[intr{irq172: qat1}]
11 0 root-92- 0B 1696K WAIT15 0:00 1.07%
[intr{irq175: qat1}]
11 0 root-92- 0B 1696K WAIT 4 0:00 1.04%
[intr{irq164: qat1}]
11 0 root-92- 0B 1696K CPU6 6 0:00 1.02%
[intr{irq166: qat1}]
11 0 root-92- 0B 1696K WAIT14 0:00 1.00%
[intr{irq174: qat1}]
11 0 root-92- 0B 1696K WAIT10 0:00 0.98%
[intr{irq170: qat1}]
11 0 root-92- 0B 1696K WAIT 5 0:00 0.98%
[intr{irq165: qat1}]
11 0 root-92- 0B 1696K WAIT 3 0:00 0.97%
[intr{irq163: qat1}]
11 0 root-92- 0B 1696K WAIT 7 0:00 0.95%
[intr{irq167: qat1}]
11 0 root-92- 0B 1696K WAIT 2 0:00 0.93%
[intr{irq162: qat1}]
stable/13 results are better then stable/12 but not enough fast. There is
something makes bottleneck for IPsec.
On Sat, May 1, 2021 at 3:39 PM Özkan KIRIK wrote:
> I've pulled the latest stable/13 branch and make buildworld.
>
> Same configuration and same usa
Re: IPsec performace - netisr hits %100
On Sat, May 01, 2021 at 04:30:59PM +0300, Özkan KIRIK wrote: > This bug is related to CCR. @Navdeep Parhar , @John Baldwin > if you are interested to fix this bug related with CCR, I > can test if you provide patches. Test environment is explained in my first > email on this thread. > > @Mark Johnston Now again on stable/13, > - with aesni, without netipsec/ipsec_input.c patch - 1.44Gbps - single > netisr thread eats %100 cpu > - with qat, without netipsec/ipsec_input.c patch - 1.88Gbps - single netisr > thread eats %100 cpu > - with aesni, with netipsec/ipsec_input.c patch - 1.33Gbps > - with qat, with netipsec/ipsec_input.c patch - 2.85Gbps - > > stable/13 results are better then stable/12 but not enough fast. There is > something makes bottleneck for IPsec. So with these results it looks like we have 4 crypto threads running, which is what I'd expect for two pairs of IP addresses. There is still a single-threaded bottleneck. I would suggest generating a flame graph using DTrace and https://github.com/brendangregg/FlameGraph to see where we're spending CPU time. It would also be useful to know if we're getting errors or drops anywhere. The QAT (sysctl dev.qat.*.stats) and ESP/AH (netstat -s -p (esp|ah)) counters would be a useful start, in addition to counters from cxgbe. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 255507] traceroute6 generates wrong UDP checksum
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255507 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org Status|New |In Progress -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPsec performace - netisr hits %100
the previous flamegraph is captured while iperf client (jail) sends to iperf server. the attached flamegraph to this mail is captured while iperf configured full-duplex mode. Throughput is about up: 1.5 Gbps down: 1.5 Gbps total: 3 Gbps On Sat, May 1, 2021 at 11:57 PM Özkan KIRIK wrote: > Hello, > The flamegraph is attached. > > # netstat -s > ... > ipsec: > 0 inbound packets violated process security policy > 0 inbound packets failed due to insufficient memory > 0 invalid inbound packets > 0 outbound packets violated process security policy > 0 outbound packets with no SA available > 0 outbound packets failed due to insufficient memory > 0 outbound packets with no route available > 0 invalid outbound packets > 0 outbound packets with bundled SAs > 0 spd cache hits > 0 spd cache misses > 0 clusters copied during clone > 0 mbufs inserted during makespace > ah: > 0 packets shorter than header shows > 0 packets dropped; protocol family not supported > 0 packets dropped; no TDB > 0 packets dropped; bad KCR > 0 packets dropped; queue full > 0 packets dropped; no transform > 0 replay counter wraps > 0 packets dropped; bad authentication detected > 0 packets dropped; bad authentication length > 0 possible replay packets detected > 0 packets in > 0 packets out > 0 packets dropped; invalid TDB > 0 bytes in > 0 bytes out > 0 packets dropped; larger than IP_MAXPACKET > 0 packets blocked due to policy > 0 crypto processing failures > 0 tunnel sanity check failures > AH output histogram: > aes-gmac-128: 35517864 > esp: > 0 packets shorter than header shows > 0 packets dropped; protocol family not supported > 0 packets dropped; no TDB > 0 packets dropped; bad KCR > 0 packets dropped; queue full > 20 packets dropped; no transform > 0 packets dropped; bad ilen > 0 replay counter wraps > 0 packets dropped; bad encryption detected > 0 packets dropped; bad authentication detected > 0 possible replay packets detected > 23598941 packets in > 11918943 packets out > 0 packets dropped; invalid TDB > 32247932688 bytes in > 630318292 bytes out > 0 packets dropped; larger than IP_MAXPACKET > 0 packets blocked due to policy > 0 crypto processing failures > 0 tunnel sanity check failures > ESP output histogram: > aes-gcm-16: 35517864 > > dev.qat.1.stats.sym_alloc_failures: 0 > dev.qat.1.stats.ring_full: 1267 > dev.qat.1.stats.gcm_aad_updates: 0 > dev.qat.1.stats.gcm_aad_restarts: 0 > dev.qat.1.%domain: 0 > dev.qat.1.%parent: pci16 > dev.qat.1.%pnpinfo: vendor=0x8086 device=0x37c8 subvendor=0x8086 > subdevice=0x class=0x0b4000 > dev.qat.1.%location: slot=0 function=0 dbsf=pci0:182:0:0 > dev.qat.1.%driver: qat > dev.qat.1.%desc: Intel C620/Xeon D-2100 QuickAssist PF > dev.qat.0.stats.sym_alloc_failures: 0 > dev.qat.0.stats.ring_full: 0 > dev.qat.0.stats.gcm_aad_updates: 0 > dev.qat.0.stats.gcm_aad_restarts: 0 > dev.qat.0.%domain: 0 > dev.qat.0.%parent: pci15 > dev.qat.0.%pnpinfo: vendor=0x8086 device=0x37c8 subvendor=0x8086 > subdevice=0x class=0x0b4000 > dev.qat.0.%location: slot=0 function=0 dbsf=pci0:181:0:0 > dev.qat.0.%driver: qat > dev.qat.0.%desc: Intel C620/Xeon D-2100 QuickAssist PF > dev.qat.%parent: > > > > > On Sat, May 1, 2021 at 5:51 PM Mark Johnston wrote: > >> On Sat, May 01, 2021 at 04:30:59PM +0300, Özkan KIRIK wrote: >> > This bug is related to CCR. @Navdeep Parhar , @John >> Baldwin >> > if you are interested to fix this bug related with >> CCR, I >> > can test if you provide patches. Test environment is explained in my >> first >> > email on this thread. >> > >> > @Mark Johnston Now again on stable/13, >> > - with aesni, without netipsec/ipsec_input.c patch - 1.44Gbps - single >> > netisr thread eats %100 cpu >> > - with qat, without netipsec/ipsec_input.c patch - 1.88Gbps - single >> netisr >> > thread eats %100 cpu >> > - with aesni, with netipsec/ipsec_input.c patch - 1.33Gbps >> > - with qat, with netipsec/ipsec_input.c patch - 2.85Gbps - >> > >> > stable/13 results are better then stable/12 but not enough fast. There >> is >> > something makes bottleneck for IPsec. >> >> So with these results it looks like we have 4 crypto threads running, >> which is what I'd expect for two pairs of IP addresses. There is still >> a single-threaded bottleneck. I would suggest generating a flame graph >> using DTrace and https://github.com/brendangregg/FlameGraph to see where >> we're spending CPU time. It would also be useful to know if we're >> getting errors or drops anywhere. The QAT (sysctl dev.qat.*.stats) and >> ESP/AH (netstat -s -p (esp|ah)) co
[Bug 230996] em/igb: Intel i210/i350: ifconfig: enabling "vlanhwtag" renders VLAN on i210/i350 NICs unusable
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230996 --- Comment #29 from Kevin Bowling --- (In reply to Kaho Toshikazu from comment #28) Can you explain how this helps? It looks to me that the current iflib_vlan_register compares two softcs as expected. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 230996] em/igb: Intel i210/i350: ifconfig: enabling "vlanhwtag" renders VLAN on i210/i350 NICs unusable
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230996 --- Comment #30 from Kaho Toshikazu --- (In reply to Kevin Bowling from comment #29) EVENTHANDLER_REGISTER seems to require (struct ifnet *) which typedef if_t at if_var.h. When a vlan interface is created/destroyed, the vlan_config/unconfig handler is called, but I can not observe any execution of iflib_vlan_register or iflib_vlan_unregister at using current code. The conversion form ctx to ifp makes execution of handlers. Then these handlers are called when a event is happened regardless for other devices or for itself. The compare is required to pick up a event related to a device driver. The handler calls with if_t because of being registered if_t instead of if_ctx_t by the above modification. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
