Re: Netmap pipe zero-copy with NIC buffer?

2017-04-11 Thread Paras Jha
Apologies, by KB I meant kernel bypass, since it is possible to open a netmap port without bypassing the kernel. I didn't know if this would affect it or not. On Sun, Apr 9, 2017 at 3:20 AM, Vincenzo Maffione wrote: > Hi, > Yes, when you nm_open("netmap:em3{2", ...), you're opening a netmap pi

[Bug 131876] [socket] FD leak by receiving SCM_RIGHTS by recvmsg with small control message buffer

2017-04-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=131876 Mark Johnston changed: What|Removed |Added Assignee|rwat...@freebsd.org |freebsd-net@FreeBSD.org

Re: interface down, console output: igb3: TX(7) desc avail = 41, pidx = 308

2017-04-11 Thread Sean Bruno
On 04/11/17 09:39, Ben Woods wrote: > Ben: > > What kind of workload is this machine processing? I'd like to try and > duplicate this failure if possible. > > sean > > > Hi Sean, > > It is a Netgate RCC-VE-8860 running as my home firewall. > https://netgate.com/docs/rcc-ve-8

Re: interface down, console output: igb3: TX(7) desc avail = 41, pidx = 308

2017-04-11 Thread Ben Woods
> > Ben: > > What kind of workload is this machine processing? I'd like to try and > duplicate this failure if possible. > > sean > > Hi Sean, It is a Netgate RCC-VE-8860 running as my home firewall. https://netgate.com/docs/rcc-ve-8860/quick-start-guide.html I am running FreeBSD 12-current r315

Re: interface down, console output: igb3: TX(7) desc avail = 41, pidx = 308

2017-04-11 Thread Sean Bruno
On 03/24/17 19:33, Ben Woods wrote: > Morning! > > Since my recent update from FreeBSD12-current r313908 to r315466, I have > noticed some strange behaviour with one of my network interfaces. > > The interface seems to work fine for a day or so, but on a number of > occasions I have found it to

Re: interface down, console output: igb3: TX(7) desc avail = 41, pidx = 308

2017-04-11 Thread Ben Woods
On 2 April 2017 at 16:04, Kevin Bowling wrote: > Sean Bruno committed a couple fixes to the watchdog code this week that > should at least allow for a usable TSO although the frequency of the > watchdog events is still cause for concern. It seems some timeouts are > part of Intel's expectations