[Bug 233114] [ix] X540 NIC drops link ("no carrier") after several runs of "pktgen -f rx -i ix0"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233114 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- 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: AQtion AQC107 driver status
Hello, Sorry for the late reply. But Benno was working on a driver. Here is his reply to me when I asked is below: https://twitter.com/jeamland/status/1059894205458182144 I haven’t had a chance to get my rig set up since the move. My code is > approaching functional but still needs work. It’s in GitHub if anyone wants > to run with it: https://github.com/jeamland/freebsd/tree/aqc Thanks, Nick Wolff On Fri, Nov 2, 2018 at 2:20 PM Zaphod Beeblebrox wrote: > I'm interested in taking a whack at this. Where's the Linux driver? I > tried searching for aquantia in the linux kernel and didn't get a hit. > > On Sun, Jun 24, 2018 at 12:51 PM Grzegorz Junka wrote: > > > Hello, > > > > As far as I could check FreeBSD doesn't yet support this card. It's > > supported in Linux kernel though. I heard somewhere that the Linux > > driver doesn't contain any binary blobs and could be ported to FreeBSD. > > Has anyone been looking into this? Or do you know if anyone is planning > > to work on the driver for this card? > > > > https://www.aquantia.com/products/client-connectivity/aqtion-aqc107/ > > > > Thanks > > GrzegorzJ > > > > ___ > > 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" > > > ___ > 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" > ___ 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 233004] ix0 at 12-BETA2: can not turn off RXCSUM/RXCSUM_IPV6
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233004 --- Comment #11 from commit-h...@freebsd.org --- A commit references this bug: Author: shurd Date: Mon Nov 12 16:08:14 UTC 2018 New revision: 340365 URL: https://svnweb.freebsd.org/changeset/base/340365 Log: MFC r340236: Fix rxcsum issue introduced in r338838 r338838 attempted to fix issues with rxcsum and rxcsum6. However, the rxcsum bits were set as though if_setcapenablebit() was being called, not if_togglecapenable() which is in use. As a result, it was not possible to disable rxcsum when rxcsum6 was supported. PR: 233004 Reported by: lev Reviewed by: lev Approved by: re (kib) Sponsored by: Limelight Networks Differential Revision:https://reviews.freebsd.org/D17881 Changes: _U stable/12/ stable/12/sys/net/iflib.c -- You are receiving this mail because: 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: epair(4) and net.route.netisr_maxqlen
On 12 Nov 2018, at 3:44, Eugene Grosbein wrote: My additions are mostly for Wolfgang, 12.11.2018 6:23, Wolfgang Zenker wrote: on a jail with quite a lot of somewhat bursty network traffic I get warnings from netdata recently about packets being dropped because of net.route.netisr_maxqlen being to small. Before I start setting this value to some random value I'ld like to find out what it actually means. A search for documentation turned up nothing; a look at the sources found that it is used for the size of a "software interrupt queue" in epair(4). But what does it mean? And does this give me enough information to find a good value to set for this sysctl? netisr packet queues keep packets received by the interface and not yet processed by destined subsystem or userland application that may be short of CPU cycles or blocked for some reason. First, the system won't allow you to raise net.route.netisr_maxqlen over the limit net.isr.maxqlimit. The limit itself can be changed with /boot/loader.conf and reboot. Default value of limit is 10240. I generally raise the limit upto 102400 for hosts with heavy/bursty traffic. Note that actual increase of net.route.netisr_maxqlen somewhat increases usage of kernel memory and that could be important for 32 bit kernel and/or system with very low amount of RAM. There may be several netisr packet queues in the system and raising net.route.netisr_maxqlen allows all of them to grow. epair(4) has its own setting net.link.epair.netisr_maxqlen that defaults to net.route.netisr_maxqlen if unset, so you may be start experimenting with net.link.epair.netisr_maxqlen first, instead of system global net.route.netisr_maxqlen. Don't set net.route.netisr_maxqlen to random value but double its current value and see if that would be enough. If not, double it again. If 4096 apears not enough, you should check your applications why they can't keep with incoming traffic rate. Also if you have multiple epair interface-combinations and a multi-core CPU you might also want to try (which never became default I think) to experiment with these settings in loader.conf: net.isr.bindthreads=1 net.isr.maxthreads=256 # net.isr will always reduce it to mp_cpus which should help balancing the load across the cores. Note: these changes also affect all other possible traffic going through the netisr framework. The netisr(9) man page has some documentation of these fields but not everything. The source code does have a lot of comments and if someone would improve the man page that might be a good start: https://svnweb.freebsd.org/base/head/sys/net/netisr.c?annotate=326272#l159 netstat -Q is also a good source for monitoring and diagnostics. /bz ___ 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"
