Date: Wed, 7 Jun 2017 23:04:16 +0200 From: Vincenzo Maffione <v.maffione@gmail.com> To: Harry Schmalzbauer <freebsd@omnilan.de> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: Re: ovs-netmap forgotten? Message-ID: <CA%2B_eA9ibDwqbY42f0UE4Pwe9xJ3Yn%2B0BOcxuHp3h8sq4iJO2DQ@mail.gmail.com> In-Reply-To: <59367CF5.9080101@omnilan.de> References: <5926FFDB.7040900@omnilan.de> <592F20A0.4020702@omnilan.de> <CA%2B_eA9i5ZJuz34WmnHfovtgX5o8a=yzpe18L8Qeoai%2B7wf4k6Q@mail.gmail.com> <592FC60A.1030308@omnilan.de> <CA%2B_eA9i4wwjXYNata6eJKBAMeAeQ2YMheeev6_juStf42EhBTQ@mail.gmail.com> <5935A20A.6040000@omnilan.de> <59367CF5.9080101@omnilan.de>
next in thread | previous in thread | raw e-mail | index | archive | help
You can play with NIC interrupt coalescing settings to keep them under control (I don't know how in FreeBSD, but in Linux you would do that with e.g. "ethtool -C rx-usecs 100"). As written in the last line of netmap(4), you must disable all the offloadings when playing with netmap physical ports. By the way, there is a person working on adding some offloading support to netmap, but this is still in progress and it is not even in the netmap github yet. Cheers, Vincenzo 2017-06-06 11:59 GMT+02:00 Harry Schmalzbauer <freebsd@omnilan.de>: > Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 05.06.2017 20:25 (loca= ltime): > > Bez=C3=BCglich Vincenzo Maffione's Nachricht vom 05.06.2017 16:06 (loca= ltime): > > > =E2=80=A6 > > First quick test shows you're right and this tiny diff solves a decent > > share of my (ESXi-replacing) problems: > > > > --- src/sys/net/if_vlan.c.orig 2017-06-05 17:39:27.770574000 +0200 > > +++ src/sys/net/if_vlan.c 2017-06-05 17:39:21.550278000 +0200 > > @@ -1234,7 +1234,7 @@ > > if_inc_counter(ifv->ifv_ifp, IFCOUNTER_IPACKETS, 1); > > > > /* Pass it back through the parent's input routine. */ > > - (*ifp->if_input)(ifv->ifv_ifp, m); > > + (*ifv->ifv_ifp->if_input)(ifv->ifv_ifp, m); > > } > > > > static int > > > > Will do real-world tests tommorrow. > > To share my observations: > > Attaching if_vlan(4) to vale(4) works with the above modification, as > long as vlanhwtag is _not_ disabled, at least with igb(4) and (em4). > Having other offloadings enabled or disabled (regardless if it's on > parent or vlan-clone) doesn't matter, disabling vlanhwtag on the parent > leads to congested parent if there's mor etraffic than console... I > haven't done any tracking if it's caused by TCP windows scaling e.g. nor > tried to ask the code, because I do want vlanhwtagging enabled and > that's what works so far :-) > This is also true for if_vlan(4) interfaces which have if_lagg(0) as > parent, and also for both types of vale(4) attaching, hoststack-detached > (-a) or hoststack-attached (-h). > So far very nice :-) > > But there's a interrupt multiplication noticeable (at the host). > > My simple NFS-copying test causes ~10ki/s at one igb(4) queue when > invoked on the host, with mtu 1500. > Same invocation in the guest, with vlan-vale setup, causes 30ki/s > average (with high discrepancy, 20-40k). > > Might it be possible that if_vlan(4) influences interrupt moderation > capabilities? > > Vincenzo, thanks for your answers to my questions, which I read during > writing of this - stripping them here. > > -harry > --=20 Vincenzo Maffione
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B_eA9ibDwqbY42f0UE4Pwe9xJ3Yn%2B0BOcxuHp3h8sq4iJO2DQ>