Date: Thu, 10 Jan 2019 22:14:42 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 226289] [igb] [netmap] Kernel NIC Driver conflict Message-ID: <bug-226289-7501-a6kviBoVtj@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-226289-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-226289-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226289 Vincenzo Maffione <vmaffione@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress --- Comment #9 from Vincenzo Maffione <vmaffione@FreeBSD.org> --- Hi, I'm sorry, I saw this only now. Long story short: this looks like your netmap application behaving incorrec= tly, or is misconfigured, and netmap duly complaining about that. Netmap uses packet buffers of fixed size, which is 2048 by default (sysctl dev.netmap.buf_size, see netmap(4)). That piece of code (netmap_grab_packets) forwards packets from the netmap "= host TX ring" (associated to the interface igb1) and injects those into the Free= BSD kernel stack, so that kernel stack "thinks" that those packets are coming f= rom the igb1 link. Who puts packets in the igb1 "host TX ring"? Well, that's an userspace netm= ap application (maybe Suricata in your deployment? It's not clear from your description. You should check in your code who is opening netmap ports with nm_open(...) or ioctl(.., NIOCREGIF, ..). Unfortunately, some of the packets written to the host TX ring look larger = than the netmap buffer size, which means that Suricata (or whoever) is setting t= he len field (in struct netmap_slot) to something larger than 2048. This is clearly wrong, and those messages mean that netmap is complaining about tha= t. So the real question is: why is your application is doing that? If you don't find an answer for that of course you can increase dev.netmap.buf_size, e.g. double it to 4096 ... The real solution to your problem may be to simply disable TSO (TCP Segmentation Offloading) and LRO (Large receive offloading) in the network interfaces of your system (through ifconfig), because TSO and LRO are likely the reason why you see packets larger than the MTU (which I assume is 1500, since you said you are not using jumbo frames). Note that TSO and LRO should always be disabled when playing with netmap (r= ead the very end of netmap(4)). --=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-226289-7501-a6kviBoVtj>