Re: RSS on FreeBSD stable/12 gateway

[Adrian Chadd]

On Sat, 13 Mar 2021 at 23:24, Özkan KIRIK  wrote:
>
> Hello Adrian,
>
> I wonder if the current RSS code supports software mode. Is it possible to 
> enforce software RSS? And what about Sender Side Scaling ?

The current RSS code does enforce it on all the NICs, so if you enable
it and you don't have hardware RSS then the kernel will rehash things
in software for you.

It has to support software RSS anyway because of how fragments work -
NICs will only do 2-tuple hashing on fragments (as there's no port
info in the fragment.) So, the received queue for the fragment doesn't
match the received-queue for the first packet in the frame, and it
ends up being reinjected correctly once the frame is fully received.

> I want to assign a snort instance for each NIC queue. Snort is configured to 
> use netmap mode. Needs and questions are below:
> - For a proper detection, both of request and response packets must enter 
> into same snort instance so that same NIC queue. For example 3way handshake 
> packets, TLS handshake packets and etc all must use same queue for both 
> directions.

Then you need to use a symmetric RSS key!

> - I'm afraid that, option RSS is only socket aware. But gateways/routers 
> doesnt have sockets for all connections. Is it possible to perform such 
> hashing and requeuing while forwarding packets?

It's .. more complicated than that.

> - On receive side, is it possible to hashing & requeuing before the netmap 
> step?
> - On sender side, is it possible to hashing & queuing before pushing in NIC 
> queue?

So, when I last left it (and what we were doing at Norse a few years ago) was:

* using RSS
* using a symmetric RSS key
* Intel ixgbe 10GB, chelso 10GB/40GB NICs would then use the system
RSS key and queue configuration.

Now, notably I haven't hacked on this since then and it's possible
something has crept in with the advent of iflib that may have messed
this up - but my intention when fixing up RSS in FreeBSD was to
continue using the notion that the whole "system" had an RSS key. All
drivers and software hashing would all use the same key and tuple
configuration where appropriate, so things would "just line up". Now,
this isn't as flexible as the Linux way where you can configure it
per-NIC but I wanted to avoid scenarios where you'd mess up the config
and suddenly your traffic didn't work right at all.



-adrian
___
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: RSS on FreeBSD stable/12 gateway

[Adrian Chadd]

On Sun, 7 Mar 2021 at 23:08, Özkan KIRIK  wrote:
>
> Thanks,
>
> I wonder that, why RSS and PCBGROUP options are not enabled in GENERIC
> kernel by default.
> Is there any performance or stability issues?

I've been running it for years at home on my desktop machine with zero issues.
However, I'm likely a special case because I hacked on it for a while. ;-)

Hans - which iflib intel hardware corrupted it? It's possible someone
undid a bunch of work I did when figuring out what the heck RSS needed
to make it actually work work, or it could be the 10/40g hardware they
shipped that was actually really broken :(



-adrian

>
> On Mon, Mar 8, 2021 at 12:26 AM Hans Petter Selasky  wrote:
>
> > On 3/7/21 10:03 PM, Özkan KIRIK wrote:
> > > Any suggestions to enable RSS ?
> >
> > I found that RSS hardware computed checksums are not correct when using
> > iflib (intel hardware), compared to what the software expects, so
> > traffic goes on wrong queue and gets dropped simply. Maybe you see
> > something similar.
> >
> > --HPS
> >
> ___
> 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"

Re: Reviewing two IPFW/netgraph/natd patches (RFC 6598/Carrier Grade NAT)

[Adrian Chadd]

hi!

On Fri, 3 Jul 2020 at 20:12, Neel Chauhan  wrote:

> Hi freebsd-hackers@, freebsd-net@,
>
> These two patches that will be described are a continuation of r357092.
>
> r357092 added support for RFC 6598/Carrier Grade NAT (subnet:
> 100.64.0.0/10) in libalias and IPFW in-kernel NAT.
>
> These two patches add support for RFC 6598 to natd and ng_nat
> respectively:
>
>   * natd CGN patch: https://reviews.freebsd.org/D23356
>   * ng_nat CGN patch: https://reviews.freebsd.org/D23461
>
> Currently, CGN support is missing from natd and ng_nat.
>
> Could someone please review and/or commit these patches?
>

I'm happy to commit these if noone complains too much to me about it.

I approved one of them. I'll go approve the other now.



-adrian


>
> Best,
>
> Neel Chauhan
>
> ===
>
> https://www.neelc.org/
> ___
> freebsd-hack...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-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"

Re: WiFi hotspot keeps dropping

[Adrian Chadd]

OH wow, I only JUST saw this, sorry!


On Sun, 21 Jun 2020 at 03:40, D'Arcy Cain  wrote:

> On 2020-06-19 12:14, Adrian Chadd wrote:
> > [snip] Also, did you plug in something USB-3 related recently? :-)
> >
> > USB-3 / USB-C's signaling frequency interferes with 2.4GHz :-)
>
> No.  The only USB-C I have is my phone which I have never plugged into the
> computer.
>
> Here's another data point.  It seems that I don't necessarily have to
> restart hostapd.  If I do "ifconfig wlan0 scan" it comes back as well.
>
>
Ok, when it next happens, do this:

sysctl dev.ath.0.forcebstuck=1

.. that forces a stuck beacon event, which resets the NIC. I wonder if the
problem is the NIC is now deaf. I fixed some issues in FreeBSD-HEAD around
noise floor calibration failures which led to NIC deafness, but you won't
even SEE that debugging unless you've compiled a custom kernel with the
above options.

Please let me know if you need any help compiling up a custom kernel.



-adrian

-- 
> D'Arcy J.M. Cain  |  Democracy is three wolves
> http://www.druid.net/darcy/|  and a sheep voting on
> +1 416 788 2246 (DoD#0082)(eNTP)   |  what's for dinner.
> IM: da...@vybenetworks.com, VoIP: sip:da...@druid.net
>
>
___
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: How to Increase TX Queue Priority for LACP Packets

[Adrian Chadd]

On Tue, 16 Jun 2020 at 17:13, Navdeep Parhar  wrote:

> We could have a global knob that tells all NIC drivers to use a reserved
> queue for non-RSS traffic, but that would be advisory at best because
> the tx queue selection takes place inside the driver's (or iflib's)
> transmit routine.  The meat of the change is going to be in iflib and
> all non-iflib drivers' if_transmit.
>

This isn't a terrible idea - we do the same on wifi for EAPOL / 802.1x
frames, and some drivers even do the same thing for DHCP frames. Doing it
in iflib would actually be kinda nice.



-adrian
___
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: WiFi hotspot keeps dropping

[Adrian Chadd]

[snip] Also, did you plug in something USB-3 related recently? :-)

USB-3 / USB-C's signaling frequency interferes with 2.4GHz :-)


-adrian

>
___
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: WiFi hotspot keeps dropping

[Adrian Chadd]

On Thu, 18 Jun 2020 at 16:37, D'Arcy Cain  wrote:

> I have set up my FreeBSD box as a gateway.  It used to work fine but
> suddenly my hotspot keeps failing.  It drops a few times a day.
> Restarting hostapd gets it back up again but I really want to keep it
> up.  I am running FreeBSD 12.1-RELEASE-p1 GENERIC  amd64.  My WiFi card is:
>
>   ath0@pci0:1:0:0: class=0x028000 card=0x30a4168c chip=0x002e168c
> rev=0x01 hdr=0x00
> vendor = 'Qualcomm Atheros'
> device = 'AR9287 Wireless Network Adapter (PCI-Express)'
> class  = network
>

Ah! AR9287! My favourite 2G only 11n NIC!


>
> It is a HP running Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz on 2 quads
> and 16GB of memory.
>
> From my rc.conf:
>
> # Internal wifi network
> wlans_ath0=wlan0
> create_args_wlan0="wlanmode hostap"
> ifconfig_wlan0="inet 192.168.225.1 netmask 0xff00 ssid druid"
> hostapd_enable=YES
> DHCPD_INTERFACES="$DHCPD_INTERFACES wlan0"
>
> If I can't keep it running can someone suggest a system test I can do to
> decide that hostapd needs to be restarted?
>

So, you shouldn't need to restart hostapd after a stuck beacon. It should
recover.


>
> One thing I found was lots of log entries like this:
>
> ath0: stuck beacon; resetting (bmiss count 4)
>

So there's plenty of reasons for a stuck beacon. I've mostly fixed the
programming problems and now it's typically really busy air.


> From reading up on that it seems that it is just a cosmetic warning.
> Could this be an indication of something that is killing the hotspot?
>

It's possible but it shouldn't be killing the interface.

What you could try is forcing a full reset every time the NIC needs to
reset.

sysctl dev.ath.0.hal.force_full_reset=1

See if that helps.

I can go whack an AR9287 into a laptop and set it up as a 2G hotspot.

What I suggest you do is recompile your kernel/modules with the following
options:

IEEE80211_DEBUG
ATH_DEBUG
AH_DEBUG
ATH_DIAGAPI

Then you'll get access to a lot more debugging tools (ie, the stuff in
tools/tools/ath/) which we can use to diagnose what's going on.




-adrian
___
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"

[Differential] D24989: netinet: Generate a random RSS key on boot.

[adrian (Adrian Chadd)]

adrian added a comment.


  i remember there was some concern in the past where there were very bad rss 
key choices out there. is there a reason for actually pushing for a random rss 
key?
  
  I stuck with the microsoft rss key (and a symmetric rss key at norse) 
specifically so there wouldn't be boot to boot variation in traffic patterns 
when doing testing/evaluation.

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D24989/new/

REVISION DETAIL
  https://reviews.freebsd.org/D24989

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: neel_neelc.org, #csprng, markm
Cc: adrian, avg, markm, cem, #csprng, kevans, debdrup, rwatson, imp, ae, 
melifaro, #contributor_reviews_base, freebsd-net-list, mmacy, 
kpraveen.lkml_gmail.com, marcnarc_gmail.com, simonvella_gmail.com, 
novice_techie.com, tommi.pernila_iki.fi, krzysztof.galazka_intel.com
___
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"

epoch and ath(4) - what should we be doing?

[Adrian Chadd]

hi!

I'd like to update ath(4) to properly work with epoch, as that whole
"oh make taskqueues epoch aware" is just not enough for ath(4).

Background:

* receive is done using deferred taskqueues, but
* receive queues are drained/handled too outside of taskqueues -
notably during interface resets, in order to not drop frames.

So I'd like to convert it over to a normal taskqueue and just manually
do EPOCH_ENTER / EPOCH_EXIT. It also means I can pepper assertions
around ath(4) and net80211(4) to ensure that we're properly entering
things with epoch held or not held.

Questions:

* are these things recursive?
* what are the rules around sleeping? I've seen some ... discussions
that were quite animated around this.
* what should I be doing as an epoch tracker if I could call the
receive routine from multiple paths. I see a few drivers have a single
place where they're doing EPOCH_ENTER/EPOCH_EXIT using an epoch
tracker allocated in the interrupt handler stack, but what if I also
want to call that receive path from another function path too? Can I
just stuff an epoch_tracker on the stack and it'll DTRT ?
* .. is there some updated doc or brain dump somewhere I can read? I'd
like to go add this to a couple out of tree wifi drivers under
development so this would make that whole thing much easier.

Thanks!


-adrian
___
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"

[Differential] D5165: [patch] dev/bwn suppressing "bwn0: unsupported rate 0" console messages

[adrian (Adrian Chadd)]

adrian added a comment.


  Yeah, we should have a fallback rate function in net80211.
  
  Why? Just to make sure that you're using the previously /negotiated/ rate, 
all the way back down to the lowest basic rate. Eg, you may not actually be 
allowed to use CCK 1Mbit rate according to the AP.
  
  the atheros rate control code does this and it .. is wrong ;(

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST ACTION
  https://reviews.freebsd.org/D5165/new/

REVISION DETAIL
  https://reviews.freebsd.org/D5165

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: mugius.0x101.freebsd_gmail.com, #network, s3erios_gmail.com
Cc: adrian, bz, imp, freebsd-net-list
___
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: 9k jumbo clusters

[Adrian Chadd]

On Fri, 27 Jul 2018 at 15:19, John-Mark Gurney  wrote:

> Ryan Moeller wrote this message on Fri, Jul 27, 2018 at 12:45 -0700:
> > There is a long-standing issue with 9k mbuf jumbo clusters in FreeBSD.
> > For example:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183381
> > https://lists.freebsd.org/pipermail/freebsd-net/2013-March/034890.html
> >
> > This comment suggests the 16k pool does not have the fragmentation
> problem:
> > https://reviews.freebsd.org/D11560#239462
> > I???m curious whether that has been confirmed.
> >
> > Is anyone working on the pathological case with 9k jumbo clusters in the
> > physical memory allocator?  There was an interesting discussion started a
> > few years ago but I???m not sure what ever came of it:
> > http://docs.freebsd.org/cgi/mid.cgi?21225.20047.947384.390241
> >
> > I have seen some work in the direction of avoiding larger than page size
> > jumbo clusters in 12-CURRENT.  Many existing drivers avoid the 9k cluster
> > size already.  The code for larger cluster sizes in iflib is #ifdef'd out
> > so it maxes out at the page size jumbo clusters until
> "CONTIGMALLOC_WORKS"
> > (apparently it doesn't).
> >
> > With all the changes due to iflib, is there any chance some of this will
> > get MFC'd to address the serious problem that remains in 11-STABLE?
> >
> > Otherwise, would it be feasible to disable the use of the 9k cluster pool
> > in at least some of the popular NIC drivers as a solution for the stable
> > branches?
> >
> > Finally, I have studied some of the driver code in 11-STABLE and posted
> the
> > gist of my notes in relation to this problem.  If anyone spots a mistake
> or
> > has something else to contribute, comments on the gist would be greatly
> > appreciated!
> > https://gist.github.com/freqlabs/eba9b755f17a223260246becfbb150a1
>
> Drivers need to be fixed to use 4k pages instead of cluster.  I really hope
> no one is using a card that can't do 4k pages, or if they are, then they
> should get a real card that can do scatter/gather on 4k pages for jumbo
> frames..


Yeah but it's 2018 and your server has like minimum a dozen million 4k
pages.

So if you're doing stuff like lots of network packet kerchunking why not
have specialised allocator paths that can do things like "hey, always give
me 64k physical contig pages for storage/mbufs because you know what?
they're going to be allocated/freed together always."

There was always a race between bus bandwidth, memory bandwidth and
bus/memory latencies. I'm not currently on the disk/packet pushing side of
things, but the last couple times I were it was at different points in that
4d space and almost every single time there was a benefit from having a
couple of specialised allocators so you didn't have to try and manage a few
dozen million 4k pages based on your changing workload.

I enjoy the 4k page size management stuff for my 128MB routers. Your 128G
server has a lot of 4k pages. It's a bit silly.




-adrian
___
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: crash with ipfw nat on mips32

[Adrian Chadd]

hi,

We figured it out today - gcc + no-arch-specific builtin bug. :-)

cognet and I are sorting through that stuff at the moment and should
land a fix in -HEAD soon.

Thanks!



-adrian



On 28 March 2018 at 02:20, Andrey V. Elsukov <bu7c...@yandex.ru> wrote:
> On 23.03.2018 20:07, Adrian Chadd wrote:
>> Hi!
>>
>> Just to keep things up to date; I had a chat with people on IRC.
>>
>> * I got the regression suite in github compiling and running on amd64.
>> I'm going to attempt to commit some makefile hilarity to get it to
>> cross-compile against the copy in sys/contrib/ck
>> * I'll go get more info when I next power up the AP in question
>>
>
> Hi Adrian,
>
> any news about this?
> I found PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225816
> it is also related to the problem.
>
> --
> WBR, Andrey V. Elsukov
>
___
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: crash with ipfw nat on mips32

[Adrian Chadd]

Hi!

Just to keep things up to date; I had a chat with people on IRC.

* I got the regression suite in github compiling and running on amd64.
I'm going to attempt to commit some makefile hilarity to get it to
cross-compile against the copy in sys/contrib/ck
* I'll go get more info when I next power up the AP in question



-adrian
___
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: crash with ipfw nat on mips32

[Adrian Chadd]

Hi,

The stack backtrace looks like a null pointer dereference.

The concurrencykit website mentions ARM and MIPS as future ports. Is
this actually true? Is concurrencykit supposed to actually run on
ARM/MIPS? Did anyone test? Actual MIPS hardware that we run on is like
$50. It's not exactly spendy to test out FreeBSD code on real
hardware. :)

I can't even build the regression suite from CK on github to run on
mips32 hardware. I don't suppose anyone would be able to figure that
particular mess out?

I'd really like to work some more on wifi stack stuff on this embedded
platform stuff and this just threw a spanner in my plans. I'd really
appreciate some help here cause I don't have time to wade through more
platform breakage just to do wifi stack / driver work. I have limited
spare time as it is these days :(

Thanks,



-adrian
___
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: ether wlan lagg works only with hint.ath.0.macaddr set (was: ether <-> wlan failover still is broken)

[Adrian Chadd]

Hi,

I keep telling people that right now it's not something I at least
have time to fix up. :)


-a

On 22 March 2018 at 08:37, Zeus Panchenko  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Andrey V. Elsukov  wrote:
>>
>> It will work, if you will change ethernet's MAC address to one, what
>> wlan interface have.
>>
>
> yes, for me it works *only* if the interface is in promiscious mode,
> just have checked
>
> BUT! what finally helped me is this:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213207#c13
>
> /boot/loader.conf
>
> hint.ath.0.macaddr="MAC:ADDRESS:OF:THE:ETHERNET:INTERFACE"
>
> - --
> Zeus V. Panchenko   jid:z...@im.ibs.dn.ua
> IT Dpt., I.B.S. LLC   GMT+2 (EET)
> -BEGIN PGP SIGNATURE-
>
> iF0EARECAB0WIQQYIXL6FUmD7SUfqoOveOk+D/ejKgUCWrPN0AAKCRCveOk+D/ej
> KqWqAKCd7GWqyXLMZtLWtOuWfR+eOVD6OQCg11ZcsR5SIsb5phXu3resUgTRnO0=
> =y2sk
> -END PGP SIGNATURE-
> ___
> 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"

Re: crash with ipfw nat on mips32

[Adrian Chadd]

I dunno yet; this is a very embedded mips74k box. :)


-a

On 22 March 2018 at 06:00, Olivier Houchard <cog...@ci0.org> wrote:
> On Thu, Mar 22, 2018 at 03:52:39PM +0300, Andrey V. Elsukov wrote:
>> On 22.03.2018 10:31, Adrian Chadd wrote:
>> > Erk. I'll go see if I can figure out what's going on.
>> >
>> > Thanks! This is really quite grr-y.
>> >>> Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode)
>> >>> [ thread pid 11 tid 100010 ]
>> >>> Stopped at  0
>> >>> db> bt
>> >>> Tracing pid 11 tid 100010 td 0x80673b40
>> >>> dyn_expire_states+0x13c (?,?,?,?) ra c1d08f44 sp c1247c40 sz 144
>> >>> dyn_tick+0x238 (0,?,?,?) ra 80214dfc sp c1247cd0 sz 120
>> >>> itimer_fire+0x1440 (?,?,?,?) ra 802150c0 sp c1247d48 sz 88
>> >>> softclock+0x9c (?,?,?,?) ra 0 sp c1247da0 sz 0
>> >>> db>
>> >>
>> >> this is not NAT related, it is ipfw's dynamic states.
>> >> I'm not sure, but this is seems related to ConcurrencyKit.
>>
>> It looks like CK doesn't declare support for mips.
>> Probably we need to make compat shim, that uses old implementation for
>> platforms, that are not supported by CK.
>>
>
> Hi,
>
> mips should be supported by using the compiler builtins, as is riscv. If there
> is a crash, it is definitively a bug. Can you guys tell me which CK
> function dies that badly ?
>
> Regards,
>
> Olivier
___
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: crash with ipfw nat on mips32

[Adrian Chadd]

oh and xcompiled with gcc-6.x .


-a

On 22 March 2018 at 09:09, Adrian Chadd <adr...@freebsd.org> wrote:
> I dunno yet; this is a very embedded mips74k box. :)
>
>
> -a
>
> On 22 March 2018 at 06:00, Olivier Houchard <cog...@ci0.org> wrote:
>> On Thu, Mar 22, 2018 at 03:52:39PM +0300, Andrey V. Elsukov wrote:
>>> On 22.03.2018 10:31, Adrian Chadd wrote:
>>> > Erk. I'll go see if I can figure out what's going on.
>>> >
>>> > Thanks! This is really quite grr-y.
>>> >>> Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode)
>>> >>> [ thread pid 11 tid 100010 ]
>>> >>> Stopped at  0
>>> >>> db> bt
>>> >>> Tracing pid 11 tid 100010 td 0x80673b40
>>> >>> dyn_expire_states+0x13c (?,?,?,?) ra c1d08f44 sp c1247c40 sz 144
>>> >>> dyn_tick+0x238 (0,?,?,?) ra 80214dfc sp c1247cd0 sz 120
>>> >>> itimer_fire+0x1440 (?,?,?,?) ra 802150c0 sp c1247d48 sz 88
>>> >>> softclock+0x9c (?,?,?,?) ra 0 sp c1247da0 sz 0
>>> >>> db>
>>> >>
>>> >> this is not NAT related, it is ipfw's dynamic states.
>>> >> I'm not sure, but this is seems related to ConcurrencyKit.
>>>
>>> It looks like CK doesn't declare support for mips.
>>> Probably we need to make compat shim, that uses old implementation for
>>> platforms, that are not supported by CK.
>>>
>>
>> Hi,
>>
>> mips should be supported by using the compiler builtins, as is riscv. If 
>> there
>> is a crash, it is definitively a bug. Can you guys tell me which CK
>> function dies that badly ?
>>
>> Regards,
>>
>> Olivier
___
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: crash with ipfw nat on mips32

[Adrian Chadd]

Erk. I'll go see if I can figure out what's going on.

Thanks! This is really quite grr-y.



-a





On 21 March 2018 at 23:35, Andrey V. Elsukov <bu7c...@yandex.ru> wrote:
> On 22.03.2018 09:23, Adrian Chadd wrote:
>> Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode)
>> [ thread pid 11 tid 100010 ]
>> Stopped at  0
>> db> bt
>> Tracing pid 11 tid 100010 td 0x80673b40
>> dyn_expire_states+0x13c (?,?,?,?) ra c1d08f44 sp c1247c40 sz 144
>> dyn_tick+0x238 (0,?,?,?) ra 80214dfc sp c1247cd0 sz 120
>> itimer_fire+0x1440 (?,?,?,?) ra 802150c0 sp c1247d48 sz 88
>> softclock+0x9c (?,?,?,?) ra 0 sp c1247da0 sz 0
>> db>
>
> Hi,
>
> this is not NAT related, it is ipfw's dynamic states.
> I'm not sure, but this is seems related to ConcurrencyKit.
>
> --
> WBR, Andrey V. Elsukov
>
___
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"

crash with ipfw nat on mips32

[Adrian Chadd]

hi,

I'm updating my freebsd wifi bits in preparation for more work and ... well:

ath1: using multicast key search
random: harvesting attach, 8 bytes (4 bits) from ath1
  .. ipfw
ipfw2 initialized, divert loadable, nat loadable, default to accept,
logging disabled
  .. ipfw_nat
*** Setting kern.random.harvest.mask=511
kern.random.harvest.mask: 2047 -> 511
*** bringing up loopback ..
Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode)
[ thread pid 11 tid 100010 ]
Stopped at  0
db> bt
Tracing pid 11 tid 100010 td 0x80673b40
dyn_expire_states+0x13c (?,?,?,?) ra c1d08f44 sp c1247c40 sz 144
dyn_tick+0x238 (0,?,?,?) ra 80214dfc sp c1247cd0 sz 120
itimer_fire+0x1440 (?,?,?,?) ra 802150c0 sp c1247d48 sz 88
softclock+0x9c (?,?,?,?) ra 0 sp c1247da0 sz 0
db>

Has anyone seen this?

FreeBSD 12.0-CURRENT #0 r331092M: Sun Mar 18 23:33:51 PDT 2018

adrian@test-2:/usr/home/adrian/work/freebsd/head-embedded/obj/mips_ap/usr/home/adrian/work/freebsd/head-embedded/src/mips.mips/sys/DIR-825C1
mips


Thanks!


-a
___
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: WiGig feature / support?

[Adrian Chadd]

hi!

There's a lot of work to do for this card. The challenge is it's a
completely different thing that our stack needs to understand /and/ it
also kinda pretends to be a PCIe end point too.

I'd start by looking at what the linux stack/driver does for 11ad.
We'd at least have to add 60GHz channel support. I don't know what
else is required for 11ad as I haven't really looked in a few years.



-adrian
___
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: run0 wifi device causes kernel panics in 11.1

[Adrian Chadd]

What's the actual stack trace? :)


-adrian


On 9 December 2017 at 10:55, Yuri  wrote:
> This started happening after I updated revision from Aug 1, 2017 to Dec 6,
> 2017.
>
> The crash stack begins at syscall_fast.
>
>
> Yuri
>
>
> ___
> 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"

Re: m_move_pkthdr leaves m_nextpkt 'dangling'

[Adrian Chadd]

On 16 October 2017 at 10:57, Gleb Smirnoff  wrote:
>   Karim,
>
> On Mon, Oct 16, 2017 at 10:37:02AM -0400, Karim Fodil-Lemelin wrote:
> K> > Not only mbufs of M_PKTHDR may have m_nextpkt set. However, I tend to 
> agree
> K> > with the patch. But shouldn't we first copy the m_nextpkt to the new 
> mbuf:
> K> >
> K> > +  to->m_nextpkt = from->m_nextpkt;
> K> > +  from->m_nextpkt = NULL;
> K> >
> K> > Same way as we deal with tags.
> K> >
> K> >
> K>
> K> I think you are correct. If we look at the 'spirit' of m_move_pkthdr();
> K> In my mind, it is to deep copy all fields related to a packet header and
> K> since m_nextpkt should only be carried by packet headers, it makes sense
> K> to copy it within m_move_pkthdr().
> K>
> K> This also raises the question (my apologies in advance from bringing
> K> this up...) of weather or not m_nextpkt belongs in struct m_hdr and not
> K> in struct pkthdr.
> K>
> K> In our case we are copying it explicitly outside the function as most of
> K> users of m_move_pkthdr() do.
>
> Moving m_nextpkt from m_hdr to m_pkthdr would be much more intrusive
> change, we can't handle that.
>
> I think an mbuf with m_nextpkt and no M_PKTRHDR is a valid one. In
> a datagram socket buffer that could hold a record. (didn't check that,
> just guessing).
>
> So, any objections on commiting this addition to m_move_pkthdr?
>
> +  to->m_nextpkt = from->m_nextpkt;
> +  from->m_nextpkt = NULL;

None from me. (I haven't checked to see if you've done it yet or not.)



-adrian

> --
> Gleb Smirnoff
___
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: m_move_pkthdr leaves m_nextpkt 'dangling'

[Adrian Chadd]

Gleb, what do you think?


-a


On 12 October 2017 at 13:42, Karim Fodil-Lemelin
<kfodil-leme...@xiplink.com> wrote:
> On 2017-07-07 10:46 AM, Andrey V. Elsukov wrote:
>>
>> On 05.07.2017 19:23, Adrian Chadd wrote:
>>>>
>>>> As many of you know, when dealing with IP fragments the kernel will
>>>> build a
>>>> list of packets (fragments) chained together through the m_nextpkt
>>>> pointer.
>>>> This is all good until someone tries to do a M_PREPEND on one of the
>>>> packet
>>>> in the chain and the M_PREPEND has to create an extra mbuf to prepend at
>>>> the
>>>> beginning of the chain.
>>>>
>>>> When doing so m_move_pkthdr is called to copy the current PKTHDR fields
>>>> (tags and flags) to the mbuf that was prepended. The function also does:
>>>>
>>>> to->m_pkthdr = from->m_pkthdr;
>>>>
>>>> This, for the case I am interested in, essentially leaves the 'from'
>>>> mbuf
>>>> with a dangling pointer m_nextpkt pointing to the next fragment. While
>>>> this
>>>> is mostly harmless because only mbufs of pkthdr types are supposed to
>>>> have
>>>> m_nextpkt it triggers some panics when running with INVARIANTS in
>>>> NetGraph
>>>> (see ng_base.c :: CHECK_DATA_MBUF(m)):
>>>>
>>>> ...
>>>>  if (n->m_nextpkt != NULL)
>>>> \
>>>>  panic("%s: m_nextpkt", __func__);
>>>> \
>>>>  }
>>>> ...
>>>>
>>>> So I would like to propose the following patch:
>>>>
>>>> @@ -442,10 +442,11 @@ m_move_pkthdr(struct mbuf *to, struct mbuf *from)
>>>>  if ((to->m_flags & M_EXT) == 0)
>>>>  to->m_data = to->m_pktdat;
>>>>  to->m_pkthdr = from->m_pkthdr;  /* especially tags */
>>>>  SLIST_INIT(>m_pkthdr.tags);   /* purge tags from src
>>>> */
>>>>  from->m_flags &= ~M_PKTHDR;
>>>> +   from->m_nextpkt = NULL;
>>>>   }
>>>>
>>>> It will reset the m_nextpkt so we don't have two mbufs pointing to the
>>>> same
>>>> next packet. This is fairly harmless and solves a problem for us here at
>>>> XipLink.
>>>
>>> This seems like a no-brainer. :-) Any objections?
>>
>> I think the change is reasonable.
>> But from other side m_demote_pkthdr() may also need this change.
>> Maybe we can wait when Gleb will be back and review this? Also he is the
>> author of the mentioned assertion in netgraph code.
>>
> Hi,
>
> Any updates on this one?
>
> There is another interesting patch I would like to share. This is regarding
> the m_tag_free function pointer in the m_tag structure.
>
> As it turns out, we use this field (m_tag_free) to track some mbuf tag at
> work and, in order to properly do reference counting on it, we had to modify
> m_tag_copy() the following way in order to keep the m_tag_free function
> pointer to point to the same function the original tag was pointing to (the
> code is a lot easier to understand than the text ...).
>
>
> @@ -437,6 +437,7 @@ m_tag_copy(struct m_tag *t, int how)
> } else
>  #endif
> bcopy(t + 1, p + 1, t->m_tag_len); /* Copy the data */
> + p->m_tag_free = t->m_tag_free;  /* copy the 'free' function pointer */
> return p;
>  }
>
> This is because m_tag_copy uses m_tag_alloc() that resets the m_tag_free
> pointer to m_tag_free_default. It would be nice if this could make its way
> into the mbuf tag base code.
>
> Best regards,
>
> Karim.
>
>
___
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: ixl(4) RSS hash type

[Adrian Chadd]

hi!

please do fix it. I'm way busy with life right now. :)



-a

On 11 September 2017 at 10:18, Eric Joyner  wrote:
> I think that sounds right; but Adrian is the one who put the code in the
> #ifdef RSS blocks in. We don't have it enabled/defined in our testing here.
>
> - Eric
>
> On Sun, Sep 10, 2017 at 8:01 PM Sepherosa Ziehau 
> wrote:
>>
>> Hi all,
>>
>> I am on the way to cleanup the UDP_IPV4_EX bit.  The only effective
>> consumer of this undefined RSS hash type is ixl.
>>
>> So I took a bit close look at it, then I have several question about
>> its hash type configuration:
>>
>> ixl_set_rss_pctypes().  It tries to set hash for IPV6 fragment, if
>> RSS_IPV6_EX is set for "options RSS".  RSS_IPV6_EX never meant IPV6
>> fragments:
>>
>> https://docs.microsoft.com/en-us/windows-hardware/drivers/network/rss-hashing-types#ndishashipv6ex
>>
>> ixl_ptype_to_hash().  As far as I understand, the decoded.outer_frag
>> means "outer packet header indicates a fragment", which has nothing to
>> do with the any of the IPV6_EX related bits:
>>
>> https://docs.microsoft.com/en-us/windows-hardware/drivers/network/rss-hashing-types
>>
>> I believe these all should be fixed.
>>
>> Thanks,
>> sephe
>>
>> --
>> Tomorrow Will Never Die
___
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: RSS_UDP_IPV4_EX?

[Adrian Chadd]

Please do!


-a


On 3 September 2017 at 17:48, Sepherosa Ziehau <sepher...@gmail.com> wrote:
> On Sat, Sep 2, 2017 at 6:11 PM, Robert N. M. Watson <rwat...@freebsd.org> 
> wrote:
>> My recollection here is (quite) hazy, as it's been a while, but it's likely
>> that this was a transcription error. The set of hash types was largely
>> modelled on what Chelsio offered in the T3 (if I recall), and also what was
>> documented in the Microsoft RSS white paper, so it may be worth taking a
>> look at those sources to see if something makes itself obvious.
>>
>> (There do seem to be some odd variations in hashing types supported by
>> various NICs -- e.g., hashing but with different hash algorithms in certain
>> generations of cards, etc, so it also wouldn't surprise me if it did
>> correspond to something real. Clearly the comment is not good enough to
>> explain that, if so!)
>
> I checked latest RSS updates from Microsoft.  There is no such type.
> But they did add UDP_IP4, UDP_IPV6 and UDP_IPV6_EX.  I am going to
> whack UDP_IPV4_EX and update various comment.  I will setup a review
> soon.
>
> Thanks,
> sephe
>
>>
>> Robert
>>
>> On 2 Sep 2017, at 00:43, Adrian Chadd <adr...@freebsd.org> wrote:
>>
>> Hi,
>>
>> I seem to recall it was something some chipsets supported? I forget the
>> details.
>>
>>
>>
>> -adrian
>>
>>
>> On 30 August 2017 at 00:07, Sepherosa Ziehau <sepher...@gmail.com> wrote:
>>>
>>> IPv4 UDP with extended headers o_O?  Or it was just a mistake.
>>>
>>> Thanks,
>>> sephe
>>>
>>> --
>>> Tomorrow Will Never Die
>>
>>
>>
>
>
>
> --
> Tomorrow Will Never Die
___
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: RSS_UDP_IPV4_EX?

[Adrian Chadd]

Hi,

I seem to recall it was something some chipsets supported? I forget the
details.



-adrian


On 30 August 2017 at 00:07, Sepherosa Ziehau  wrote:

> IPv4 UDP with extended headers o_O?  Or it was just a mistake.
>
> Thanks,
> sephe
>
> --
> Tomorrow Will Never Die
>
___
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: m_move_pkthdr leaves m_nextpkt 'dangling'

[Adrian Chadd]

On 30 June 2017 at 08:42, Karim Fodil-Lemelin
 wrote:
> Hi,
>
> As many of you know, when dealing with IP fragments the kernel will build a
> list of packets (fragments) chained together through the m_nextpkt pointer.
> This is all good until someone tries to do a M_PREPEND on one of the packet
> in the chain and the M_PREPEND has to create an extra mbuf to prepend at the
> beginning of the chain.
>
> When doing so m_move_pkthdr is called to copy the current PKTHDR fields
> (tags and flags) to the mbuf that was prepended. The function also does:
>
> to->m_pkthdr = from->m_pkthdr;
>
> This, for the case I am interested in, essentially leaves the 'from' mbuf
> with a dangling pointer m_nextpkt pointing to the next fragment. While this
> is mostly harmless because only mbufs of pkthdr types are supposed to have
> m_nextpkt it triggers some panics when running with INVARIANTS in NetGraph
> (see ng_base.c :: CHECK_DATA_MBUF(m)):
>
> ...
> if (n->m_nextpkt != NULL)   \
> panic("%s: m_nextpkt", __func__);   \
> }
> ...
>
> So I would like to propose the following patch:
>
> @@ -442,10 +442,11 @@ m_move_pkthdr(struct mbuf *to, struct mbuf *from)
> if ((to->m_flags & M_EXT) == 0)
> to->m_data = to->m_pktdat;
> to->m_pkthdr = from->m_pkthdr;  /* especially tags */
> SLIST_INIT(>m_pkthdr.tags);   /* purge tags from src */
> from->m_flags &= ~M_PKTHDR;
> +   from->m_nextpkt = NULL;
>  }
>
> It will reset the m_nextpkt so we don't have two mbufs pointing to the same
> next packet. This is fairly harmless and solves a problem for us here at
> XipLink.

This seems like a no-brainer. :-) Any objections?



-adrian
___
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: three multicast fixes

[Adrian Chadd]

Actually - into individual reviews.freebsd.org reviews?



-adrian


On 26 April 2017 at 14:53, Adrian Chadd <adrian.ch...@gmail.com> wrote:
> hiya,
>
> can you throw these in bugs?
>
>
> -a
>
>
> On 17 April 2017 at 06:58, Chris Torek <to...@torek.net> wrote:
>> The first is mostly cosmetic, it's just something I observed when
>> I turned on multicast debug to find the bug that the second patch
>> is for.
>>
>> The second patch is a kludge and if anyone has a better fix, have
>> at it.  :-) Note that it's also hard to provoke the bug.  The only
>> way I know to observe it somewhat reliably is to create and
>> destroy bridge interfaces, using a debug kernel with memory debug
>> enabled, while adding and deleting hardware interfaces to the
>> bridge so that they repeatedly join and leave multicast groups.
>> Eventually you hit the race and crash.
>>
>> The third is simple enough to observe.  It may affect only the lagg
>> driver, which implements SIOCDELMULTI by removing and re-adding all
>> the multicast addresses other than the one actually deleted (which
>> is of course really-removed by then).  If running lagg on a VIMAGE
>> kernel, leaving a multicast group causes this occasional crash:
>>
>>   Fatal trap 12: page fault while in kernel mode
>>   cpuid = 0; apic id = 00
>>   fault virtual address   = 0x28
>>   fault code  = supervisor read data, page not present
>>   instruction pointer = 0x20:0x80adf6ea
>>   stack pointer   = 0x28:0xfe009117e810
>>   frame pointer   = 0x28:0xfe009117e8b0
>>   code segment= base 0x0, limit 0xf, type 0x1b
>>   = DPL 0, pres 1, long 1, def32 0, gran 1
>>   processor eflags= interrupt enabled, resume, IOPL = 0
>>   current process = 0 (thread taskq)
>>
>>   rt_newmaddrmsg() at rt_newmaddrmsg+0x2a/frame 0xfe009117e8b0
>>   if_addmulti() at if_addmulti+0x24c/frame 0xfe009117e940
>>   lagg_ether_cmdmulti() at lagg_ether_cmdmulti+0x168/frame 0xfe009117e980
>>   lagg_ioctl() at lagg_ioctl+0xad/frame 0xfe009117ea60
>>   in_leavegroup() at in_leavegroup+0xb9/frame 0xfe009117eab0
>>   inp_gcmoptions() at inp_gcmoptions+0x1a8/frame 0xfe009117eb20
>>   taskqueue_run_locked() at taskqueue_run_locked+0x117/frame 
>> 0xfe009117eb80
>>   taskqueue_thread_loop() at taskqueue_thread_loop+0xc8/frame 
>> 0xfe009117ebb0
>>   fork_exit() at fork_exit+0x85/frame 0xfe009117ebf0
>>   fork_trampoline() at fork_trampoline+0xe/frame 0xfe009117ebf0
>>   --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>>
>> Here, "curvnet" is NULL in the lagg_ioctl(), so that when
>> rt_newmaddrmsg() does:
>>
>> if (V_route_cb.any_count == 0)
>>
>> we crash with the offset of the per-vnet route_cb data.
>>
>> (The patches are in Git format, I applied them to the read-only
>> freebsd master tree on GitHub.)
>>
>> Chris
>>
>> From 65145b74d3dae68feddcf8a2aad235c3f0a981e9 Mon Sep 17 00:00:00 2001
>> From: Chris Torek <chris.to...@gmail.com>
>> Date: Mon, 8 Feb 2016 18:55:30 -0800
>> Subject: [PATCH 1/3] ip multicast debug: fix strings vs defines
>>
>> Turning on multicast debug made multicast failure worse
>> because the strings and #define values no longer matched
>> up.  Fix them, and make sure they stay matched-up.
>> ---
>>  sys/netinet/in_mcast.c | 31 +--
>>  1 file changed, 21 insertions(+), 10 deletions(-)
>>
>> diff --git a/sys/netinet/in_mcast.c b/sys/netinet/in_mcast.c
>> index c7fff9463128..eef560e7aca7 100644
>> --- a/sys/netinet/in_mcast.c
>> +++ b/sys/netinet/in_mcast.c
>> @@ -2920,7 +2920,14 @@ sysctl_ip_mcast_filters(SYSCTL_HANDLER_ARGS)
>>
>>  #if defined(KTR) && (KTR_COMPILE & KTR_IGMPV3)
>>
>> -static const char *inm_modestrs[] = { "un", "in", "ex" };
>> +static const char *inm_modestrs[] = {
>> +   [MCAST_UNDEFINED] = "un",
>> +   [MCAST_INCLUDE] = "in",
>> +   [MCAST_EXCLUDE] = "ex",
>> +};
>> +_Static_assert(MCAST_UNDEFINED == 0 &&
>> +  MCAST_EXCLUDE + 1 == nitems(inm_modestrs),
>> +  "inm_modestrs: no longer matches #defines");
>>
>>  static const char *
>>  inm_mode_str(const int mode)
>> @@ -2932,16 +2939,20 @@ inm_mode_str(const int mode)
>>  }
>>
>>  static const char *inm_statestrs[] = 

Re: three multicast fixes

[Adrian Chadd]

hiya,

can you throw these in bugs?


-a


On 17 April 2017 at 06:58, Chris Torek  wrote:
> The first is mostly cosmetic, it's just something I observed when
> I turned on multicast debug to find the bug that the second patch
> is for.
>
> The second patch is a kludge and if anyone has a better fix, have
> at it.  :-) Note that it's also hard to provoke the bug.  The only
> way I know to observe it somewhat reliably is to create and
> destroy bridge interfaces, using a debug kernel with memory debug
> enabled, while adding and deleting hardware interfaces to the
> bridge so that they repeatedly join and leave multicast groups.
> Eventually you hit the race and crash.
>
> The third is simple enough to observe.  It may affect only the lagg
> driver, which implements SIOCDELMULTI by removing and re-adding all
> the multicast addresses other than the one actually deleted (which
> is of course really-removed by then).  If running lagg on a VIMAGE
> kernel, leaving a multicast group causes this occasional crash:
>
>   Fatal trap 12: page fault while in kernel mode
>   cpuid = 0; apic id = 00
>   fault virtual address   = 0x28
>   fault code  = supervisor read data, page not present
>   instruction pointer = 0x20:0x80adf6ea
>   stack pointer   = 0x28:0xfe009117e810
>   frame pointer   = 0x28:0xfe009117e8b0
>   code segment= base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, long 1, def32 0, gran 1
>   processor eflags= interrupt enabled, resume, IOPL = 0
>   current process = 0 (thread taskq)
>
>   rt_newmaddrmsg() at rt_newmaddrmsg+0x2a/frame 0xfe009117e8b0
>   if_addmulti() at if_addmulti+0x24c/frame 0xfe009117e940
>   lagg_ether_cmdmulti() at lagg_ether_cmdmulti+0x168/frame 0xfe009117e980
>   lagg_ioctl() at lagg_ioctl+0xad/frame 0xfe009117ea60
>   in_leavegroup() at in_leavegroup+0xb9/frame 0xfe009117eab0
>   inp_gcmoptions() at inp_gcmoptions+0x1a8/frame 0xfe009117eb20
>   taskqueue_run_locked() at taskqueue_run_locked+0x117/frame 
> 0xfe009117eb80
>   taskqueue_thread_loop() at taskqueue_thread_loop+0xc8/frame 
> 0xfe009117ebb0
>   fork_exit() at fork_exit+0x85/frame 0xfe009117ebf0
>   fork_trampoline() at fork_trampoline+0xe/frame 0xfe009117ebf0
>   --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>
> Here, "curvnet" is NULL in the lagg_ioctl(), so that when
> rt_newmaddrmsg() does:
>
> if (V_route_cb.any_count == 0)
>
> we crash with the offset of the per-vnet route_cb data.
>
> (The patches are in Git format, I applied them to the read-only
> freebsd master tree on GitHub.)
>
> Chris
>
> From 65145b74d3dae68feddcf8a2aad235c3f0a981e9 Mon Sep 17 00:00:00 2001
> From: Chris Torek 
> Date: Mon, 8 Feb 2016 18:55:30 -0800
> Subject: [PATCH 1/3] ip multicast debug: fix strings vs defines
>
> Turning on multicast debug made multicast failure worse
> because the strings and #define values no longer matched
> up.  Fix them, and make sure they stay matched-up.
> ---
>  sys/netinet/in_mcast.c | 31 +--
>  1 file changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/sys/netinet/in_mcast.c b/sys/netinet/in_mcast.c
> index c7fff9463128..eef560e7aca7 100644
> --- a/sys/netinet/in_mcast.c
> +++ b/sys/netinet/in_mcast.c
> @@ -2920,7 +2920,14 @@ sysctl_ip_mcast_filters(SYSCTL_HANDLER_ARGS)
>
>  #if defined(KTR) && (KTR_COMPILE & KTR_IGMPV3)
>
> -static const char *inm_modestrs[] = { "un", "in", "ex" };
> +static const char *inm_modestrs[] = {
> +   [MCAST_UNDEFINED] = "un",
> +   [MCAST_INCLUDE] = "in",
> +   [MCAST_EXCLUDE] = "ex",
> +};
> +_Static_assert(MCAST_UNDEFINED == 0 &&
> +  MCAST_EXCLUDE + 1 == nitems(inm_modestrs),
> +  "inm_modestrs: no longer matches #defines");
>
>  static const char *
>  inm_mode_str(const int mode)
> @@ -2932,16 +2939,20 @@ inm_mode_str(const int mode)
>  }
>
>  static const char *inm_statestrs[] = {
> -   "not-member",
> -   "silent",
> -   "idle",
> -   "lazy",
> -   "sleeping",
> -   "awakening",
> -   "query-pending",
> -   "sg-query-pending",
> -   "leaving"
> +   [IGMP_NOT_MEMBER] = "not-member",
> +   [IGMP_SILENT_MEMBER] = "silent",
> +   [IGMP_REPORTING_MEMBER] = "reporting",
> +   [IGMP_IDLE_MEMBER] = "idle",
> +   [IGMP_LAZY_MEMBER] = "lazy",
> +   [IGMP_SLEEPING_MEMBER] = "sleeping",
> +   [IGMP_AWAKENING_MEMBER] = "awakening",
> +   [IGMP_G_QUERY_PENDING_MEMBER] = "query-pending",
> +   [IGMP_SG_QUERY_PENDING_MEMBER] = "sg-query-pending",
> +   [IGMP_LEAVING_MEMBER] = "leaving",
>  };
> +_Static_assert(IGMP_NOT_MEMBER == 0 &&
> +  IGMP_LEAVING_MEMBER + 1 == nitems(inm_statestrs),
> +  "inm_statetrs: no longer matches #defines");
>
>  static const char *
>  inm_state_str(const int state)
> --
> 2.12.1
>
>
> From 

Re: altq and head

[Adrian Chadd]

It'll be supported as much as someone is willing to pay for it.

It isn't out of the realm of possibility to implement an if_transmit
style layer for altq, etc so it could be a generic queue discipline.
It'd be nice to have a multi-queue version of this but we're not there
yet.

Thanks,



-adrian

On 25 April 2017 at 07:43, Nick Rogers  wrote:
> On Sat, Apr 8, 2017 at 3:55 AM, Eugene M. Zheganin  wrote:
>> Hi,
>>
>> regarding all this stir around ALTQ and igb(4), and mentioning that igb(4)
>> doesn't have ALTQ in HEAD - I wanted to ask - is this just igb(4) and
>> ixgbe(4) that lost ALTQ in HEAD, or is ALTQ being removed totally from
>> FreeBSD ? I did a couple of searches, but seems like I cannot find the
>> simple answer.
>
> I'm also curious what the plan is w.r.t ALTQ. I definitely depend on
> igb supporting it... Thanks.
>
>>
>>
>> Thanks.
>>
>> Eugene.
>>
>> ___
>> 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"

Re: Intel Dual Band Wireless AC 8260

[Adrian Chadd]

Hiya,

Ok, maybe the channel lists are different. 116/140 are in the DFS range..


-adrian
___
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: Intel Dual Band Wireless AC 8260

[Adrian Chadd]

Yeah I know :( I'm still trying to find spare cycles to keep moving
the driver forward to the latest dfbsd code.

At least we know which commit broke it..


-a


On 20 February 2017 at 15:57, Kevin Bowling  wrote:
> It used to work pretty well, but HEAD regressed heavily.  My card crashes
> 8260 non-stop.
>
> I'm trying to resync everything to DFBSD, I will post a review if
> successful.
>
> On Mon, Feb 20, 2017 at 4:50 PM, Andreas Nilsson  wrote:
>
>> Hello,
>>
>> I have a laptop with an Intel Dual Band Wireless AC 8260 card (
>> iwm0@pci0:4:0:0:
>>class=0x028000 card=0x11308086 chip=0x24f38086 rev=0x3a hdr=0x00 )
>> in my thinkpad x1 yoga.
>>
>> I'm running 12-CURRENT, and wireless is sort of working, although very
>> slowly: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11a where I would
>> expect more. My old trusted access point is a wndr3700 which supports 11n (
>> worked fine with my macbook, regularly got 20Mb/s.
>>
>> I bought a new access point to get that 11ac goodness, but I can barley get
>> my new laptop to find the anything on the 5GHz band.
>>
>> So my questions:
>> -Does FreeBSD actually support 11ac yet?
>> -Shouldn't my ac8260 support 11n as well?
>> -Should I get different scan results depending on if have my old or new ap
>> connected?
>> -How come my t510 thinkpad (different os btw) can see my 5GHz net on my new
>> ap but my yoga does not?
>>
>> Best regards
>> Andreas
>> ___
>> 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"

Re: Intel Dual Band Wireless AC 8260

[Adrian Chadd]

Hiya,


On 20 February 2017 at 15:50, Andreas Nilsson  wrote:
> Hello,
>
> I have a laptop with an Intel Dual Band Wireless AC 8260 card (
> iwm0@pci0:4:0:0:
>class=0x028000 card=0x11308086 chip=0x24f38086 rev=0x3a hdr=0x00 )
> in my thinkpad x1 yoga.
>
> I'm running 12-CURRENT, and wireless is sort of working, although very
> slowly: IEEE 802.11 Wireless Ethernet OFDM/54Mbps mode 11a where I would
> expect more. My old trusted access point is a wndr3700 which supports 11n (
> worked fine with my macbook, regularly got 20Mb/s.

The 7260 and later chipset driver (iwm) doesn't yet support 11n or 11ac, sorry!

>
> I bought a new access point to get that 11ac goodness, but I can barley get
> my new laptop to find the anything on the 5GHz band.
>
> So my questions:
> -Does FreeBSD actually support 11ac yet?

I'm working on it. I have it working in my ath10k driver port, but
there aren't any drivers with 11ac support in -head.

> -Shouldn't my ac8260 support 11n as well?

Yes, but not yet.

> -Should I get different scan results depending on if have my old or new ap
> connected?

Nope, but scanning isn't always going to return the same results.

> -How come my t510 thinkpad (different os btw) can see my 5GHz net on my new
> ap but my yoga does not?

Try "ifconfig -v wlan0 list channel" and let's see what's going on.
Which channel is the 5GHz net on with the new AP?

Thanks,



-adrian
___
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: RFC: ethctl

[Adrian Chadd]

On 19 January 2017 at 19:58, Kevin Bowling  wrote:
> Greetings,
>
> I'm casting a wide net in cc, try to keep the noise minimal but we need
> some input from a variety of HW vendors.
>
> I have heard from several vendors the need for a NIC configuration tool.
>  Chelsio ships a cxgb/cxgbetool in FreeBSD as one example.  There is
> precedence for some nod toward a basic unified tool in Linux ethtool.
>
> From your perspective,
> 1) What are the common requirements?
> 2) What are specialized requirements? For instance as a full TCP offload
> card Chelsio needs things others wont
> 3) What should it _not_ do?  Several of you have experience doing Ethernet
> driver dev on many platforms so we should attempt to avoid repeating past
> design mistakes.
>
> I expect we can achieve some level of inversion so the device specific code
> can live close to the driver and plug into the ethctl framework.  It should
> be general enough to add completely new top level commands, so vendors can
> implement HW specific features.  On the other hand, we should attempt to
> hook into common core for features every NIC provides, with a focus on
> iflib.
>
> I will fund Matt Macy to do the overall design and implementation.
>
> Regards,
> Kevin Bowling, on behalf of Limelight Networks for this effort

Hi,

ethtool isn't exactly complicated. It's just vaguely standardized.

When I was hoping (hah!) to do it, partly for wifi but partly for
ethernet, my goals were:

* generic interface for counter statistics, versus sysctl;
* "default" mib space for known counter statistics, versus the small
set we have now and then the very large vendor space that ethtool
(linux) and sysctl (freebsd) exposes;
* generic interface for configuring things like RSS mapping, L2/L3
rules for a NIC based on the NIC capability and what queue(s) they map
to, versus vendor tools;
* vendor specific extensions, which hopefully (!) are implemented as
generic-ish plugins where required, or just strings that can be passed
through to the driver and registered via a command hook;
* and importantly - some kind of optional debug control, because every
driver does something different for debugging / tracing, and boy it'd
be nice if it all was like wifi (wlandebug -i 
+/-(feature))

A lot of what's in linux ethtool is in freebsd's ifconfig, albeit not
in a reusable/runtime-extensible fashion. It'd be nice to include say,
many more vendor counters in a somewhat generic fashion, versus how we
currently do things.

I think it'd be a good starting point to have an ethtool control iflib
drivers, so any driver using iflib can benefit from what's
implemented.

2c,

-adrian
___
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"

[Differential] D9270: Add support for user-supplied Host-Uniq tag in Netgraph PPPoE

[adrian (Adrian Chadd)]

adrian accepted this revision.
adrian added a reviewer: adrian.
This revision has a positive review.

REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D9270

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: ale, #manpages, julian, #network, adrian
Cc: mandree, imp, freebsd-net-list
___
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: FLOWTABLE aka TCP route caching panic

[Adrian Chadd]

i can reproduce this daily using flowtable on a wifi enabled PC on -HEAD.



-adrian

On 12 January 2017 at 06:13, Jakub Palider  wrote:
> An update: eventually, FLOWTABLE option also resulted in crash with
> __rw_lock_hard on FreeBSD release/11.0.0 (also on VM).
> This time, however, the backtrace was different, instead of
> tcp_output->ip_output->ether_output() chain, it happened in
> flowtable_clean_vnet()
>
> On Wed, Jan 11, 2017 at 10:42 AM, Jakub Palider  wrote:
>
>> On Tue, 29 Nov 2016 11:05:09 -0800
>> Gleb Smirnoff  wrote:
>>
>> > On Mon, Nov 28, 2016 at 02:10:33PM -0800, hiren panchasara wrote:
>> > h> > Hi,
>> > h> > I have found that last month (19 Oct) the problem appeared on this
>> list,
>> > h> > and to my experience it persists, both on VM and bare metal
>> installation
>> > h> > (HEAD from yesterday). I looks that enabling FLOWTABLE option is
>> the only
>> > h> > source of this fault happening. It appears on our setup in 80%
>> cases within
>> > h> > one hour from boot up.
>> > h> > From our debugging, it is caused by lock on DESTROYED lock. Did you
>> find a
>> > h> > solution to this problem?
>> >
>> > Not yet.
>> >
>> > I'm pretty sure that reverting my r307234 will fix your crashes.
>> However, I still
>> > believe that r307234 is a proper way of fixing things, not r300854 which
>> just
>> > plugged the problem in the nearest place to the crash. But as we all see
>> r307234
>> > is definitely missing some code path, which still allows for stale route
>> to be
>> > referenced.
>> >
>> > --
>> > Totus tuus, Glebius.
>>
>> Thank you for your pointer, in helped at some point. The problem
>> however returned, especially when under heavy, continuous load. We are
>> running 4 iperf3 processes, each having 4 threads, and the machine
>> dies after 30-60 minutes of TCP traffic. I am running  rS3092 from
>> Nov 24.
>> On FreeBSD 11.0-RELEASE this problem (1 full day of testing) was not
>> noticed. Could you point to related commits that might also influence
>> this behaviour?
>> Thanks,
>> Jakub
>>
> ___
> 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"

Re: Changing NIC ring weight in indirection table

[Adrian Chadd]

yeah, adrian is currently busy doing non-paid wifi work, so getting
onto non-paid RSS configuration work is taking a backburner.

Patches gratefully accepted though!


-a


On 3 January 2017 at 17:19, Sepherosa Ziehau  wrote:
> On Fri, Dec 30, 2016 at 11:34 PM, David Belle-Isle  
> wrote:
>> Hi,
>>
>> Can anyone tell me how to set the weight of a ring from the indirection
>> table on FreeBSD? My plan is to yank out a TX ring and to use it solely
>> with netmap to receive packets but want to make sure the kernel won't be
>> receiving any packets on this ring.
>
> TX side is not related to the RSS's indirect table at all.  I believe
> you need to modify the drivers you are using.
>
>>
>> Based on a quick search this is something that ethtool would be able to do
>> on Linux but I doubt this can be done on FreeBSD using the same tool?
>
> adrian@ has proposed something in this area, RSS key and RSS indirect
> table, though not much happens yet.  I have implemented the indirect
> table changes through a driver specific sysctl for hn(4), you probably
> could do the same for the drivers that you are using.  But again, you
> will have to change the code.
>
> Thanks,
> sephe
___
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: cxgbe's native netmap support broken since r307394

[Adrian Chadd]

Hi,

I'll do it in a sec.


-a


On 30 December 2016 at 01:11, Vincenzo Maffione <v.maffi...@gmail.com> wrote:
> Ok! Can anyone commit this?
> Luigi seems to be ok with the change.
>
> Thanks,
>   Vincenzo
>
> 2016-12-29 19:16 GMT+01:00 John Baldwin <j...@freebsd.org>:
>> On Thursday, December 29, 2016 10:02:32 AM Vincenzo Maffione wrote:
>>> Ok, thanks for the clarification. I change the lock type to MTX_DEF
>>> (and did a test). I attached the new patch.
>>
>> Looks good to me, thanks!
>>
>>> Cheers,
>>>   Vincenzo
>>>
>>> 2016-12-29 2:06 GMT+01:00 John Baldwin <j...@freebsd.org>:
>>> > On Wednesday, December 28, 2016 07:25:22 PM Vincenzo Maffione wrote:
>>> >> Hi,
>>> >>   The "worker_lock" is taken by nm_os_kthread_wakeup_worker(), which
>>> >> in turn is called by nm_pt_host_notify(). The latter function is a
>>> >> callback that may be called by a driver interrupt service routine;
>>> >> more precisely this happens when the driver calls netmap_tx_irq() or
>>> >> netmap_rx_irq(). As far as I know in FreeBSD it is not possible to
>>> >> lock a MTX_DEF mtx inside an ISR. Am I wrong on this?
>>> >
>>> > It depends.  Most interrupt handlers run in ithreads and can use MTX_DEF.
>>> > Only interrupt handlers that run from a filter are restricted to using
>>> > MTX_SPIN.  Looking at all the calls to netmap_[tr]x_irq() in the tree,
>>> > they are all done from contexts that are safe to use MTX_DEF (and in
>>> > general they have to be as the equivalent code for the non-netmap case
>>> > is calling routines like if_input or m_freem that can't be invoked from
>>> > a filter either).
>>> >
>>> >>
>>> >> Cheers,
>>> >>   Vincenzo
>>> >>
>>> >> 2016-12-28 19:06 GMT+01:00 John Baldwin <j...@freebsd.org>:
>>> >> > Why are you using MTX_SPIN?  Changing the lock type to MTX_DEF would 
>>> >> > seem to
>>> >> > be a smaller patch and probably more correct for FreeBSD.
>>> >> >
>>> >> > On Thursday, December 22, 2016 05:29:41 PM Luigi Rizzo wrote:
>>> >> >> sure go ahead and thank you!
>>> >> >>
>>> >> >> On Thu, Dec 22, 2016 at 5:15 PM, Adrian Chadd 
>>> >> >> <adrian.ch...@gmail.com> wrote:
>>> >> >> > ok, does anyone mind if I commit it as-is?
>>> >> >> >
>>> >> >> >
>>> >> >> > -a
>>> >> >> >
>>> >> >> >
>>> >> >> > On 21 December 2016 at 13:37, Vincenzo Maffione 
>>> >> >> > <v.maffi...@gmail.com> wrote:
>>> >> >> >> Hi Luigi,
>>> >> >> >>   I attached a minimal change containing two fixes:
>>> >> >> >>
>>> >> >> >> - change IFNET_WLOCK into IFNET_RLOCK, to fix the cxgbe issue 
>>> >> >> >> related
>>> >> >> >> to this thread
>>> >> >> >> - use the proper locking functions for the "worker_lock", unrelated
>>> >> >> >> but needed to avoid the O.S. to trap because of a mismatch between
>>> >> >> >> MTX_SPIN and MTX_DEF.
>>> >> >> >>
>>> >> >> >> Cheers,
>>> >> >> >>   Vincenzo
>>> >> >> >>
>>> >> >> >> 2016-12-21 20:30 GMT+01:00 Luigi Rizzo <ri...@iet.unipi.it>:
>>> >> >> >>> On Wed, Dec 21, 2016 at 11:15 AM, Vincenzo Maffione
>>> >> >> >>> <v.maffi...@gmail.com> wrote:
>>> >> >> >>>> Hi,
>>> >> >> >>>>   There is no commit related to that in the FreeBSD svn or git.
>>> >> >> >>>>
>>> >> >> >>>> The fix has been published to the github netmap repository here
>>> >> >> >>>> (branch master): https://github.com/luigirizzo/netmap
>>> >> >> >>>>
>>> >> >> >>>> What we should do is to import all the recent updates from the 
>>> >> >> >>>> github
>>> >> >> >>>>

Re: cxgbe's native netmap support broken since r307394

[Adrian Chadd]

ok, does anyone mind if I commit it as-is?


-a


On 21 December 2016 at 13:37, Vincenzo Maffione <v.maffi...@gmail.com> wrote:
> Hi Luigi,
>   I attached a minimal change containing two fixes:
>
> - change IFNET_WLOCK into IFNET_RLOCK, to fix the cxgbe issue related
> to this thread
> - use the proper locking functions for the "worker_lock", unrelated
> but needed to avoid the O.S. to trap because of a mismatch between
> MTX_SPIN and MTX_DEF.
>
> Cheers,
>   Vincenzo
>
> 2016-12-21 20:30 GMT+01:00 Luigi Rizzo <ri...@iet.unipi.it>:
>> On Wed, Dec 21, 2016 at 11:15 AM, Vincenzo Maffione
>> <v.maffi...@gmail.com> wrote:
>>> Hi,
>>>   There is no commit related to that in the FreeBSD svn or git.
>>>
>>> The fix has been published to the github netmap repository here
>>> (branch master): https://github.com/luigirizzo/netmap
>>>
>>> What we should do is to import all the recent updates from the github
>>> into HEAD. I can prepare a patch for HEAD, if you wish. Just let me
>>> know.
>>
>> I just checked and the diff between FreeBSD head and netmap head
>> in github is almost 3k lines due to a lot of recent refactoring.
>> So, if there is an easy way to extract just the locking change that would
>> be preferable as an interim solution.
>>
>> cheers
>> luigi
>>
>>>
>>> Cheers,
>>>   Vincenzo
>>>
>>>
>>> 2016-12-20 21:45 GMT+01:00 Adrian Chadd <adrian.ch...@gmail.com>:
>>>> hi,
>>>>
>>>> What's the commit? We should get it into -HEAD asap.
>>>>
>>>>
>>>> -adrian
>>>>
>>>>
>>>> On 20 December 2016 at 01:25, Vincenzo Maffione <v.maffi...@gmail.com> 
>>>> wrote:
>>>>> Ok, applied to the netmap github repo.
>>>>> This fix will be published when Luigi does the next commit on FreeBSD.
>>>>>
>>>>> Cheers,
>>>>>   Vincenzo
>>>>>
>>>>> 2016-12-19 20:05 GMT+01:00 Navdeep Parhar <n...@freebsd.org>:
>>>>>> IFNET_RLOCK will work, thanks.
>>>>>>
>>>>>> Navdeep
>>>>>>
>>>>>> On Mon, Dec 19, 2016 at 3:21 AM, Vincenzo Maffione 
>>>>>> <v.maffi...@gmail.com> wrote:
>>>>>>> Hi Navdeep,
>>>>>>>
>>>>>>>   Indeed, we have reviewed the code, and we think it is ok to
>>>>>>> implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using
>>>>>>> IFNET_WLOCK().
>>>>>>> Since IFNET_RLOCK() results into sx_slock(), this should fix the issue.
>>>>>>>
>>>>>>> On FreeBSD, this locking is needed to protect a flag read by 
>>>>>>> nm_iszombie().
>>>>>>> However, on Linux the same lock is also needed to protect the call to
>>>>>>> the nm_hw_register() callback, so we prefer to have an "unified"
>>>>>>> locking scheme, i.e. always calling nm_hw_register under the lock.
>>>>>>>
>>>>>>> Does this make sense to you? Would it be easy for you to make a quick
>>>>>>> test by replacing IFNET_WLOCK with IFNET_RLOCK?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>   Vincenzo
>>>>>>>
>>>>>>> 2016-12-17 23:28 GMT+01:00 Navdeep Parhar <n...@freebsd.org>:
>>>>>>>> Luigi, Vincenzo,
>>>>>>>>
>>>>>>>> The last major update to netmap (r307394 and followups) broke cxgbe's
>>>>>>>> native netmap support.  The problem is that netmap_hw_reg now holds an
>>>>>>>> rw_lock around the driver's netmap_on/off routines.  It has always been
>>>>>>>> safe for the driver to sleep during these operations but now it panics
>>>>>>>> instead.
>>>>>>>>
>>>>>>>> Why is IFNET_WLOCK needed here?  It seems like a regression to disallow
>>>>>>>> sleep on the control path.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Navdeep
>>>>>>>>
>>>>>>>> begin_synchronized_op with the following non-sleepable locks held:
>>>>>>>> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0x8271d680) locked @

Re: cxgbe's native netmap support broken since r307394

[Adrian Chadd]

hi,

What's the commit? We should get it into -HEAD asap.


-adrian


On 20 December 2016 at 01:25, Vincenzo Maffione  wrote:
> Ok, applied to the netmap github repo.
> This fix will be published when Luigi does the next commit on FreeBSD.
>
> Cheers,
>   Vincenzo
>
> 2016-12-19 20:05 GMT+01:00 Navdeep Parhar :
>> IFNET_RLOCK will work, thanks.
>>
>> Navdeep
>>
>> On Mon, Dec 19, 2016 at 3:21 AM, Vincenzo Maffione  
>> wrote:
>>> Hi Navdeep,
>>>
>>>   Indeed, we have reviewed the code, and we think it is ok to
>>> implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using
>>> IFNET_WLOCK().
>>> Since IFNET_RLOCK() results into sx_slock(), this should fix the issue.
>>>
>>> On FreeBSD, this locking is needed to protect a flag read by nm_iszombie().
>>> However, on Linux the same lock is also needed to protect the call to
>>> the nm_hw_register() callback, so we prefer to have an "unified"
>>> locking scheme, i.e. always calling nm_hw_register under the lock.
>>>
>>> Does this make sense to you? Would it be easy for you to make a quick
>>> test by replacing IFNET_WLOCK with IFNET_RLOCK?
>>>
>>> Thanks,
>>>   Vincenzo
>>>
>>> 2016-12-17 23:28 GMT+01:00 Navdeep Parhar :
 Luigi, Vincenzo,

 The last major update to netmap (r307394 and followups) broke cxgbe's
 native netmap support.  The problem is that netmap_hw_reg now holds an
 rw_lock around the driver's netmap_on/off routines.  It has always been
 safe for the driver to sleep during these operations but now it panics
 instead.

 Why is IFNET_WLOCK needed here?  It seems like a regression to disallow
 sleep on the control path.

 Regards,
 Navdeep

 begin_synchronized_op with the following non-sleepable locks held:
 exclusive rw ifnet_rw (ifnet_rw) r = 0 (0x8271d680) locked @
 /root/ws/head/sys/dev/netmap/netmap_freebsd.c:95
 stack backtrace:
 #0 0x810837a5 at witness_debugger+0xe5
 #1 0x81084d88 at witness_warn+0x3b8
 #2 0x83ef2bcc at begin_synchronized_op+0x6c
 #3 0x83f14beb at cxgbe_netmap_reg+0x5b
 #4 0x809846f1 at netmap_hw_reg+0x81
 #5 0x809806de at netmap_do_regif+0x19e
 #6 0x8098121d at netmap_ioctl+0x7ad
 #7 0x8098682f at freebsd_netmap_ioctl+0x5f
>>>
>>>
>>>
>>> --
>>> Vincenzo Maffione
>>> ___
>>> 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"
>
>
>
> --
> Vincenzo Maffione
> ___
> 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"

ipfw broken on mips

[Adrian Chadd]

Hiya!

I'm using ipfw on mips, and I've found it recently broke. Any ipfw
command (eg ipfw -a l) says

ipfw: ipfw_ctl3 invalid option 0v0
ipfw: setsockopt(IP_FW_xxx): Invalid argument

Who broke it? :)



-adrian
___
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: Regression WPA? 10.2 -> 10.3 stopped working

[Adrian Chadd]

What do you mean with "urtwn0 exists from usb bus" ?



-adrian


On 18 September 2016 at 14:28, Ze Claudio Pastore <zclau...@bsd.com.br> wrote:
> I took longer than expected, got new dongles just to make sure.
>
> What I have tested an conclusions:
>
> - 11.0-RC2: same problem persists, exactly the same
> - 10.3: kernel with 10.2 userland: different error, urtwn0 exists from usb
> bus, probably related to the kernel/userland mismatch than a real error
> - 10.3: with a live usb stick (official), exactly the same problem as with
> 10.3 upgraded with freebsd-update
> - 10.2: works perfectly with all dongles
>
> Do you want any debug info I can provide on the working system or a
> nonworking one?
>
> Best,
> Z.
>
>
>
>
>
>
>
>
> 2016-09-15 14:49 GMT-03:00 Adrian Chadd <adrian.ch...@gmail.com>:
>
>> Thanks! I do care; I use wifi daily here in both hostap and sta modes
>> (and soon hopefully ibss and wds!) so i really do try to keep it
>> going!
>>
>>
>> -a
>>
>>
>> On 13 September 2016 at 08:14, Ze Claudio Pastore <zclau...@bsd.com.br>
>> wrote:
>> > I will boot from a live stick by the evening and try the same dongles
>> just
>> > to isolate if a plain new 10.3 is also broken or if it's just a matter
>> of an
>> > unhappy upgrade and report back, thanks for caring :)
>> >
>> > 2016-09-13 12:12 GMT-03:00 Ze Claudio Pastore <zclau...@bsd.com.br>:
>> >>
>> >> No, I have'nt, is it possible w/ freebsd-update? Can I revert just the
>> >> userland?
>> >>
>> >>
>> >>
>> >> 2016-09-13 0:15 GMT-03:00 Adrian Chadd <adrian.ch...@gmail.com>:
>> >>>
>> >>> Hi!
>> >>>
>> >>> have you tried say, 10.3 kernel with 10.2 userland? does it still work?
>> >>>
>> >>>
>> >>>
>> >>> -adrian
>> >>
>> >>
>> >
>>
> ___
> 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"

Re: Regression WPA? 10.2 -> 10.3 stopped working

[Adrian Chadd]

Thanks! I do care; I use wifi daily here in both hostap and sta modes
(and soon hopefully ibss and wds!) so i really do try to keep it
going!


-a


On 13 September 2016 at 08:14, Ze Claudio Pastore <zclau...@bsd.com.br> wrote:
> I will boot from a live stick by the evening and try the same dongles just
> to isolate if a plain new 10.3 is also broken or if it's just a matter of an
> unhappy upgrade and report back, thanks for caring :)
>
> 2016-09-13 12:12 GMT-03:00 Ze Claudio Pastore <zclau...@bsd.com.br>:
>>
>> No, I have'nt, is it possible w/ freebsd-update? Can I revert just the
>> userland?
>>
>>
>>
>> 2016-09-13 0:15 GMT-03:00 Adrian Chadd <adrian.ch...@gmail.com>:
>>>
>>> Hi!
>>>
>>> have you tried say, 10.3 kernel with 10.2 userland? does it still work?
>>>
>>>
>>>
>>> -adrian
>>
>>
>
___
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: Regression WPA? 10.2 -> 10.3 stopped working

[Adrian Chadd]

Hi!

have you tried say, 10.3 kernel with 10.2 userland? does it still work?



-adrian
___
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: iwn(4) association issues in 11-Stable (and maybe RC)

[Adrian Chadd]

IWN_DEBUG worked, it's 'dev.iwn.0.debug', not 'debug.iwn.0.debug'. My bad.

Make sure you build the module by doing 'buildkernel', not 'cd
sys/modules/iwn && make', as (because reasons I want to grr) we don't
enforce that people put in a path to their kernel config .h directory,
so it defaults to "some arbitrary options".


-a


On 24 August 2016 at 15:42, Kevin Oberman  wrote:
> On Wed, Aug 24, 2016 at 12:45 PM, Glen Barber  wrote:
>>
>> On Wed, Aug 24, 2016 at 12:20:57PM -0700, Kevin Oberman wrote:
>> > 
>> > On Wed, Aug 24, 2016 at 12:03 PM, Glen Barber  wrote:
>> >
>> > > On Wed, Aug 24, 2016 at 11:55:13AM -0700, Kevin Oberman wrote:
>> > > > Not working right. I do see 802.11 messages but nothing from iwn.
>> > > > Rebuilt with:
>> > > > optionsIEEE80211_DEBUG
>> > > > optionsIWN_DEBUG
>> > > >
>> > > > [...]
>> > > >
>> > > > Any idea what is going on?
>> > >
>> > > Your original email mentions 11.0-BETA4.  Are you still running
>> > > stable/11?  If so, could you please update to r304715?  If running
>> > > releng/11.0, the matching commit is r304719.
>> > >
>> >
>> > Since my initial post I have updated to r304734 (running 11-STABLE). I
>> > did
>> > that before rebuilding my kernel with the DEBUG options as it was
>> > already
>> > three weeks old. So this does not seem to have fixed the issue.
>>
>> Dumb question, but with reason.
>>
>> Does ifconfig(8) actually show wlan0 'UP'?
>>
>> I'm asking this because I'm seeing something strange locally on one
>> machine.
>>
>> Glen
>
>
> I have stopped and started the network repeatedly using both my home router
> and my hot-spot and I can't get it to fail. It associates the first time
> every time. I'm about ready to chalk up my one failure with the new kernel
> as a fluke. I'll continue testing later today, but this one may be resolved.
>
> I'll also rebuild my kernel without the debug options just in case the
> slight timing change had some impact on this.
>
> Thanks to both Glen and Adrian for helping me look into this. Still have no
> idea why IWN_DEBUG didn't seem to work.
> --
> R. Kevin Oberman, Network Engineer
> E-mail: kob6...@gmail.com
___
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: iwn(4) association issues in 11-Stable (and maybe RC)

[Adrian Chadd]

hi

Would /someone/ pretty please fix this "run wpa_supplicant multiple
times at interface start" problem?

I'm sure it's screwing things up in a bad way, and trying to grovel
around and fix the way we do rc scripts is not my favourite thing in
the world.

Thanks,


-adrian


On 24 August 2016 at 13:23, Glen Barber  wrote:
> On Wed, Aug 24, 2016 at 08:19:21PM +, Glen Barber wrote:
>> On Wed, Aug 24, 2016 at 01:11:21PM -0700, Kevin Oberman wrote:
>> > On Aug 24, 2016 12:46 PM, "Glen Barber"  wrote:
>> >
>> > > On Wed, Aug 24, 2016 at 12:20:57PM -0700, Kevin Oberman wrote:
>> > > > 
>> > > > On Wed, Aug 24, 2016 at 12:03 PM, Glen Barber  wrote:
>> > > >
>> > > > > On Wed, Aug 24, 2016 at 11:55:13AM -0700, Kevin Oberman wrote:
>> > > > > > Not working right. I do see 802.11 messages but nothing from iwn.
>> > > > > > Rebuilt with:
>> > > > > > optionsIEEE80211_DEBUG
>> > > > > > optionsIWN_DEBUG
>> > > > > >
>> > > > > > [...]
>> > > > > >
>> > > > > > Any idea what is going on?
>> > > > >
>> > > > > Your original email mentions 11.0-BETA4.  Are you still running
>> > > > > stable/11?  If so, could you please update to r304715?  If running
>> > > > > releng/11.0, the matching commit is r304719.
>> > > > >
>> > > >
>> > > > Since my initial post I have updated to r304734 (running 11-STABLE). I
>> > > did
>> > > > that before rebuilding my kernel with the DEBUG options as it was 
>> > > > already
>> > > > three weeks old. So this does not seem to have fixed the issue.
>> > >
>> > > Dumb question, but with reason.
>> > >
>> > > Does ifconfig(8) actually show wlan0 'UP'?
>> > >
>> > > I'm asking this because I'm seeing something strange locally on one
>> > > machine.
>> > >
>> >
>> > I have been unable to catch it, so I don't know.  I know the UP/DOWN
>> > sequences in the first log showed many per second and all in the same
>> > second. In this case it was UP for 13 seconds, so something was different.
>> >
>> > I will try to test some more later,  but I have to go out for a couple of
>> > hours right now.
>> >
>>
>> Ok, thanks.  This is different than the issue I'm seeing, part of which
>> turned out to be a config issue on one of two machines, but completely
>> odd on the other.
>>
>
> Sigh.  On my side, it was a config issue on both machines.  Sorry for
> the noise, but I'm sure you understand my concern and panic this late in
> 11.0.
>
> Glen
>
___
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: iwn(4) association issues in 11-Stable (and maybe RC)

[Adrian Chadd]

Hi,

Compile in IWN_DEBUG and IEEE80211_DEBUG and then do:

wlandebug +assoc +auth +state +rate
sysctl debug.iwn.0.debug=0x1

that's TX debugging, and it hopefully will show it trying to do
association and failing. My guess is that something changed when doing
the 11n bits for -11 and it's failing to send out the 802.1x frame
exchange.

It may be something as simple as "adrian needs to fix the rate control again".



-adrian
___
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: svn commit: r304313 - head/sys/net

[Adrian Chadd]

On 21 August 2016 at 07:42, Robert N. M. Watson <rwat...@freebsd.org> wrote:
> On 20 Aug 2016, at 21:27, Adrian Chadd <adr...@freebsd.org> wrote:
>
>> I wonder if the right-er thing to do here is to allow the cpuid to be
>> whatever it needs to be, but limit the cpuid lookups when it resolves
>> to a netisr array.
>>
>> that'd mean the hybrid model would still return the current CPU up to
>> the max CPU id, but anything trying to queue into a netisr would not
>> overflow the netisr queue count.
>
>
> I think some refinement of model is required. The original intent was that 
> “workstreams” represented ordered sets of queues being delivered for deferred 
> dispatch across the set of CPUs (hence “nws” being allocated using DPCPU). 
> When performing direct dispatch, as a matter of convenience, we also bill 
> work performed on a CPU to its workstream:
>
>  1109 /*
>  1110  * If direct dispatch is forced, then unconditionally dispatch
>    * without a formal CPU selection.  Borrow the current CPU's 
> stats,
>  1112  * even if there's no worker on it.  In this case we don't 
> update
>  1113  * nws_flags because all netisr processing will be source 
> ordered due
>  1114  * to always being forced to directly dispatch.
>  1115  */
>
> In hybrid mode, the world is a little different, because we are willing to 
> direct dispatch hybrid work *only* if the worker thread isn’t already 
> processing the workstream:
>
>  1147 /*-
>  1148  * We are willing to direct dispatch only if three conditions 
> hold:
>  1149  *
>  1150  * (1) The netisr worker isn't already running,
>  1151  * (2) Another thread isn't already directly dispatching, and
>  1152  * (3) The netisr hasn't already been woken up.
>  1153  */
>
> This is important because if the workstream already has a backlog of work, 
> but the thread isn’t yet running, we must enqueue the work to ensure it 
> remains ordered with respect to other work in the workstream.
>
> Assuming we wish to retain the current workstream model, then we need to 
> adapt the code a bit to handle the case where we still have one workstream 
> per CPU, but where we are only willing to perform deferred dispatch (or 
> hybrid dispatch) to a CPU that has a worker thread. We would then bill to any 
> CPU’s workstream for true direct dispatch, but for hybrid dispatch, continue 
> to always bill a CPU that has a worker thread to which we were willing to 
> assign the work.
>
> I.e., as I think you’re suggesting, we probably need to tweak the functions 
> slightly to differentiate between “you can run it here and must use curcpu’s 
> workstream” and “you can run it here but must use a specific CPU’s 
> workstream” — the former being true direct dispatch, and the latter being 
> hybrid dispatch where the netisr in question isn’t already running, but we 
> bill it to that workstream/netisr even though we run it on the current CPU.
>
> Does this make sense?

Right. Let me go and look into it a little more. I think we may want
to revert the change (which just landed to -11, so maybe revert that
too) so I can test both of them out for correctness.

Andrey, I'm sorry for suggesting we back it out, but I'd like to make
sure we don't break networking on 11. :) Is that okay? I will look at
this tonight/tomorrow.



-adrian
___
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: iwn(4) association issues in 11-Stable (and maybe RC)

[Adrian Chadd]

On 20 August 2016 at 19:02, Kevin Oberman <kob6...@gmail.com> wrote:
> On Aug 20, 2016 6:29 PM, "Adrian Chadd" <adrian.ch...@gmail.com> wrote:
>>
>> Hi,
>>
>> There have been some changes to the scan code and iwn scan timeout code.
>> Andriy may have some ideas.
>>
>> Thanks!
>>
>> A
>
> One more note. There are multiple "link up" messages in the log. The LED
> never stopped the flashing which indicates that it is not associated. If I
> did "ifconfig wlan0 list aps", my hot spot was listed, but a simple
> "ifconfig wlan0" never showed an association. Usually a few "netif restart"s
> will get it to work, but sometimes it seems hopeless. It seems worse when my
> phone is the hot spot than with my home router.

I've not seen this happen with any of the iwn hardware that I have,
but wifi is odd like that.

it looks like wpa_supplicant is started twice. Is that happening? That
(sigh) still may be making things unhappy.



-adrian
___
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: iwn(4) association issues in 11-Stable (and maybe RC)

[Adrian Chadd]

Hi,

There have been some changes to the scan code and iwn scan timeout code.
Andriy may have some ideas.

Thanks!

A

On Aug 19, 2016 3:48 PM, "Kevin Oberman"  wrote:

> Lately I have had serious issues with my system successfully associating.
> These were not present with 10.3.
>
> > uname -a
> FreeBSD rogue 11.0-BETA4 FreeBSD 11.0-BETA4 #1 r303806: Sat Aug  6 18:50:50
> PDT 2016 root@rogue:/usr/obj/usr/src/sys/GENERIC.4BSD  amd64
>
> iwn0@pci0:3:0:0:class=0x028000 card=0x13118086 chip=0x00858086
> rev=0x34
> hdr=0x00
> cap 01[c8] = powerspec 3  supports D0 D3  current D0
> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) FLR RO NS
>  link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1)
> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected
> ecap 0003[140] = Serial 1 a088b4c6ad28
>
> Once associated, it works fine, but a dropped association is often not
> re-established and the network fails to come up at boot time. Kernel is
> GENERIC except the 4BSD scheduler.
>
> I've been using a mobile hotspot this week during travels and it has become
> a real pain. With  lot of patience and many "netif restart wlan0"
> operations, it will come up, but it can be painful. Here is what I see in
> messages:
> Aug 19 00:13:52 rogue kernel: wlan0: Ethernet address: a0:88:b4:c6:ad:28
> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN
> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout
> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN
> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout
> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN
> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout
> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN
> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout
> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN
> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout
> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN
> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout
> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN
> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout
> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP
> Aug 19 00:13:52 rogue kernel: ipfw2 (+ipv6) initialized, divert loadable,
> nat loadable, default to deny, logging disabled
> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN
> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout
> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601
> Aug 19 00:14:17 rogue dhclient[362]: send_packet: Network is down
> Aug 19 00:14:37 rogue dhclient[362]: send_packet: Network is down
> Aug 19 00:14:39 rogue wpa_supplicant[350]: wlan0: CTRL-EVENT-TERMINATING
> Aug 19 00:14:39 rogue dhclient[362]: connection closed
> Aug 19 00:14:39 rogue dhclient[362]: exiting.
> Aug 19 00:14:39 rogue rtsold[873]:  interface
> wlan0 removed
> Aug 19 00:14:39 rogue kernel: wlan0: Ethernet address: a0:88:b4:c6:ad:28
> Aug 19 00:14:39 rogue wpa_supplicant[1621]: Successfully initialized
> wpa_supplicant
> Aug 19 00:14:39 rogue wpa_supplicant[1633]: Successfully initialized
> wpa_supplicant
> Aug 19 00:14:39 rogue root: /etc/rc.d/wpa_supplicant: WARNING: failed to
> start wpa_supplicant
> Aug 19 00:14:39 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601
> Aug 19 00:14:39 rogue wpa_supplicant[1634]: ioctl[SIOCS80211, op=103,
> val=0, arg_len=128]: Operation now in progress
> Aug 19 00:14:39 rogue wpa_supplicant[1634]: wlan0: CTRL-EVENT-SCAN-FAILED
> ret=-1 retry=1
> Aug 19 00:14:40 rogue wpa_supplicant[1634]: ioctl[SIOCS80211, op=103,
> val=0, arg_len=128]: Operation now in progress
> Aug 19 00:14:40 rogue wpa_supplicant[1634]: wlan0: CTRL-EVENT-SCAN-FAILED
> ret=-1 retry=1
> Aug 19 00:14:41 rogue wpa_supplicant[1634]: 

Re: svn commit: r304313 - head/sys/net

[Adrian Chadd]

On 17 August 2016 at 13:21, Andrey V. Elsukov  wrote:
> Author: ae
> Date: Wed Aug 17 20:21:33 2016
> New Revision: 304313
> URL: https://svnweb.freebsd.org/changeset/base/304313
>
> Log:
>   Teach netisr_get_cpuid() to limit a given value to supported by netisr.
>   Use netisr_get_cpuid() in netisr_select_cpuid() to limit cpuid value
>   returned by protocol to be sure that it is not greather than nws_count.
>
>   PR:   211836
>   Reviewed by:  adrian
>   MFC after:3 days
>
> Modified:
>   head/sys/net/if_epair.c
>   head/sys/net/netisr.c
>
> Modified: head/sys/net/if_epair.c
> ==
> --- head/sys/net/if_epair.c Wed Aug 17 19:43:45 2016(r304312)
> +++ head/sys/net/if_epair.c Wed Aug 17 20:21:33 2016(r304313)
> @@ -807,9 +807,9 @@ epair_clone_create(struct if_clone *ifc,
>  * cache locality but we can at least allow parallelism.
>  */
> sca->cpuid =
> -   netisr_get_cpuid(sca->ifp->if_index % netisr_get_cpucount());
> +   netisr_get_cpuid(sca->ifp->if_index);
> scb->cpuid =
> -   netisr_get_cpuid(scb->ifp->if_index % netisr_get_cpucount());
> +   netisr_get_cpuid(scb->ifp->if_index);
>
> /* Initialise pseudo media types. */
> ifmedia_init(>media, 0, epair_media_change, epair_media_status);
>
> Modified: head/sys/net/netisr.c
> ==
> --- head/sys/net/netisr.c   Wed Aug 17 19:43:45 2016(r304312)
> +++ head/sys/net/netisr.c   Wed Aug 17 20:21:33 2016(r304313)
> @@ -272,10 +272,7 @@ u_int
>  netisr_get_cpuid(u_int cpunumber)
>  {
>
> -   KASSERT(cpunumber < nws_count, ("%s: %u > %u", __func__, cpunumber,
> -   nws_count));
> -
> -   return (nws_array[cpunumber]);
> +   return (nws_array[cpunumber % nws_count]);
>  }
>
>  /*
> @@ -810,10 +807,12 @@ netisr_select_cpuid(struct netisr_proto
>  * dispatch.  In the queued case, fall back on the SOURCE
>  * policy.
>  */
> -   if (*cpuidp != NETISR_CPUID_NONE)
> +   if (*cpuidp != NETISR_CPUID_NONE) {
> +   *cpuidp = netisr_get_cpuid(*cpuidp);
> return (m);
> +   }
> if (dispatch_policy == NETISR_DISPATCH_HYBRID) {
> -   *cpuidp = curcpu;
> +   *cpuidp = netisr_get_cpuid(curcpu);
> return (m);
> }
> policy = NETISR_POLICY_SOURCE;
>

I wonder if the right-er thing to do here is to allow the cpuid to be
whatever it needs to be, but limit the cpuid lookups when it resolves
to a netisr array.

that'd mean the hybrid model would still return the current CPU up to
the max CPU id, but anything trying to queue into a netisr would not
overflow the netisr queue count.

Thoughts?


-a
___
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: Unstable local network throughput

[Adrian Chadd]

On 17 August 2016 at 08:43, Ben RUBSON <ben.rub...@gmail.com> wrote:
>
>> On 17 Aug 2016, at 17:38, Adrian Chadd <adrian.ch...@gmail.com> wrote:
>>
>> [snip]
>>
>> ok, so this is what I was seeing when I was working on this stuff last.
>>
>> The big abusers are:
>>
>> * so_snd lock, for TX'ing producer/consumer socket data
>> * tcp stack pcb locking (which rss tries to work around, but it again
>> doesn't help producer/consumer locking, only multiple sockets)
>> * for some of the workloads, the scheduler spinlocks are pretty
>> heavily contended and that's likely worth digging into.
>>
>> Thanks! I'll go try this on a couple of boxes I have with
>> intel/chelsio 40g hardware in it and see if I can reproduce it. (My
>> test boxes have the 40g NICs in NUMA domain 1...)
>
> You're welcome, happy to help and troubleshoot :)
>
> What about the performance which differs from one reboot to another,
> as if the NUMA domains have switched ? (0 to 1 & 1 to 0)
> Did you already see this ?

I've seen some varying behaviours, yeah. There are a lot of missing
pieces in kernel-side NUMA, so a lot of the kernel memory allocation
behaviours are undefined. Well, tehy'e defined; it's just there's no
way right now for the kernel (eg mbufs, etc) to allocate domain local
memory. So it's "by accident", and sometimes it's fine; sometimes it's
not.



-adrian
___
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: Unstable local network throughput

[Adrian Chadd]

[snip]

ok, so this is what I was seeing when I was working on this stuff last.

The big abusers are:

* so_snd lock, for TX'ing producer/consumer socket data
* tcp stack pcb locking (which rss tries to work around, but it again
doesn't help producer/consumer locking, only multiple sockets)
* for some of the workloads, the scheduler spinlocks are pretty
heavily contended and that's likely worth digging into.

Thanks! I'll go try this on a couple of boxes I have with
intel/chelsio 40g hardware in it and see if I can reproduce it. (My
test boxes have the 40g NICs in NUMA domain 1...)



-adrian
___
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: Unstable local network throughput

[Adrian Chadd]

On 16 August 2016 at 02:58, Ben RUBSON <ben.rub...@gmail.com> wrote:
>
>> On 16 Aug 2016, at 03:45, Adrian Chadd <adrian.ch...@gmail.com> wrote:
>>
>> Hi,
>>
>> ok, can you try 5) but also running with the interrupt threads pinned to CPU 
>> 1?
>
> What do you mean by interrupt threads ?
>
> Perhaps you mean the NIC interrupts ?
> In this case see 6) and 7) where NIC IRQs are pinned to CPUs 0-11 (6) and 
> 11-23 (7) ?

Hm, interesting. ok. So, I wonder what the maximum per-domain memory
throughput is.

I don't have any other easy things to instrument right now - the
"everything disabled" method likely works best because of how the
system is interleaving memory for you (instead of the OS trying to do
it). Not pinning things means latency can be kept down to work around
lock contention (ie, if a lock is held by thread A, and thread B needs
to make some progress, it can make progress on another CPU , keeping
CPU A held for a shorter period of time.)

Would you mind compiling in LOCK_PROFILING and doing say, these tests
with lock profiling enabled? It'll impact performance, sure, but I'd
like to see what the locking looks like.

sysctl debug.lock.prof.reset=1
sysctl debug.lock.prof.enable=1
(run test for a few seconds)
sysctl debug.lock.prof.enable=0
sysctl debug.lock.prof.stats (and capture)

* interrupts - domain 0, work - domain 1
* interrupts - domain 1, work - domain 1
* interrupts - domain 1, work - domain 0

Thanks!



-adrian
___
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: Unstable local network throughput

[Adrian Chadd]

Hi,

ok, can you try 5) but also running with the interrupt threads pinned to CPU 1?

It looks like the interrupt threads are running on CPU 0, and my
/guess/ (looking at the CPU usage distributions) that sometimes the
userland bits run on the same CPU or numa domain as the interrupt
bits, and it likely decreases some latency -> increasing throughput
slightly.

Thanks,



-adrian
___
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: Panic in stable/11 (amd64) @r303903: page fault while in kernel mode

[Adrian Chadd]

i don't know what's different between stable/11 and -head. I'd
appreciate some help in figuring /that/ out...


-a


On 12 August 2016 at 15:53, David Wolfskill <da...@catwhisker.org> wrote:
> On Fri, Aug 12, 2016 at 03:44:43PM -0700, Adrian Chadd wrote:
>> Heh, ok. So undo the #if 0 and let's just see if it crashes or not.
>> ...
>
> Well, as things presently stand, I can't use wlan0 at work except in
> head (which I haven't hacked, and I am running now).
>
> If I boot stable/11, I can only exercise wlan0 if I use it (wlano) --
> which I can't if I can't get a DHCP lease.
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> Those who would murder in the name of God or prophet are blasphemous cowards.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
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: Panic in stable/11 (amd64) @r303903: page fault while in kernel mode

[Adrian Chadd]

Heh, ok. So undo the #if 0 and let's just see if it crashes or not.



-adrian

On 12 August 2016 at 15:13, David Wolfskill <da...@catwhisker.org> wrote:
> On Fri, Aug 12, 2016 at 02:37:44PM -0700, Adrian Chadd wrote:
>> Hi
>>
>> Just #if 0 that whole chunk out and see if that improves wireless at work?
>> 
>
> That didn't seem to change the behavior in any observable way.
>
> So I tried booting stable/10... which wouldn't even associate.
>
> As I type, I'm presently booting head:
>
> FreeBSD localhost 12.0-CURRENT FreeBSD 12.0-CURRENT #72  
> r304004M/304004:121: Fri Aug 12 04:54:09 PDT 2016 
> r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
>
> which managed to associate (after a couple false starts) and managed
> to acquire a DHCP lease, as well.
>
> Errr  yeah.
>
> I remain happy to do directed hacks & testing
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> Those who would murder in the name of God or prophet are blasphemous cowards.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
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: Panic in stable/11 (amd64) @r303903: page fault while in kernel mode

[Adrian Chadd]

Hi

Just #if 0 that whole chunk out and see if that improves wireless at work?


-a


On 12 August 2016 at 14:18, David Wolfskill <da...@catwhisker.org> wrote:
> On Fri, Aug 12, 2016 at 11:40:03AM -0700, Adrian Chadd wrote:
>> EIther stable/11 or head. Both are fine.
>>
>>
>>
>> -a
>>
>>
>> On 12 August 2016 at 11:05, David Wolfskill <da...@catwhisker.org> wrote:
>> > On Fri, Aug 12, 2016 at 11:01:25AM -0700, Adrian Chadd wrote:
>> >> David,
>> >>
>> >> Totally untested; will need manual application as I bet this patch is 
>> >> mangled.
>> >>
>> >> Would you mind testing this? I have a feeling we need to add if_addr
>> >> lock calls in a few places.
>> >
>> > Sure; I'll test.  Which branch?
>> >
>> > Please note that "lack of recurrence" of the panic isn't especially
>> > indiciative, as I hadn't seen it previously or since.  (Then again,
>> > yestrday & today, I've been using the wired NIC on the laptop while I'm
>> > at work, as the laptop has been unable to get a DHCP lease here.  (It
>> > worked OK at Hacker Dojo last night, and works OK at home.)
>> >
>> ...
>
> OK; up & runing:
>
> FreeBSD localhost 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #72  
> r303979M/304004:1100500: Fri Aug 12 13:57:30 PDT 2016 
> root@localhost:/common/S2/obj/usr/src/sys/CANARY  amd64
>
> [Copy/paste...]
> localhost(11.0-P)[1] cd /usr/src/
> localhost(11.0-P)[2] svn diff sys/net80211/
> Index: sys/net80211/ieee80211_ioctl.c
> ===
> --- sys/net80211/ieee80211_ioctl.c  (revision 304004)
> +++ sys/net80211/ieee80211_ioctl.c  (working copy)
> @@ -3389,15 +3389,16 @@
> /* Wait for parent ioctl handler if it was queued */
> if (wait) {
> ieee80211_waitfor_parent(ic);
> -
> /*
>  * Check if the MAC address was changed
>  * via SIOCSIFLLADDR ioctl.
>  */
> +   if_addr_rlock(ifp);
> if ((ifp->if_flags & IFF_UP) == 0 &&
> !IEEE80211_ADDR_EQ(vap->iv_myaddr, 
> IF_LLADDR(ifp)))
> IEEE80211_ADDR_COPY(vap->iv_myaddr,
> IF_LLADDR(ifp));
> +   if_addr_runlock(ifp);
> }
> break;
> case SIOCADDMULTI:
> localhost(11.0-P)[3]
>
>
> That said, I am unable to test use of wireless here at work at this
> time, as I am unable to obtain a DHCP lease now (I am presently
> connected via em0 NIC):
>
> ...
> Aug 12 21:04:15  console-kit-daemon[970]: WARNING: Error waiting for native 
> console 1 activation: Inappropriate ioctl for device
> Aug 12 21:04:15  kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 
> type mismatch - Found [Buffer], ACPI requires [Package] 
> (20160527/nsarguments-97)
> Aug 12 21:04:15  last message repeated 11 times
> Aug 12 21:04:22  wpa_supplicant[373]: wlan0: CTRL-EVENT-SSID-REENABLED id=25 
> ssid="$work_SSID"
> Aug 12 21:04:22  wpa_supplicant[373]: wlan0: Trying to associate with 
> 04:bd:88:18:18:82 (SSID='$work_SSID' freq=2462 MHz)
> Aug 12 21:04:22  wpa_supplicant[373]: wlan0: Associated with 04:bd:88:18:18:82
> Aug 12 21:04:22  kernel: wlan0: link state changed to UP
> Aug 12 21:04:22  dhclient: /etc/dhclient-enter-hooks invoked with reason 
> EXPIRE
> Aug 12 21:04:22  dhclient: Ignoring claimed EXPIRE dhclient invocation
> Aug 12 21:04:22  dhclient[393]: send_packet: No buffer space available
> Aug 12 21:04:22  dhclient[393]: send_packet: No buffer space available
> Aug 12 21:04:22  wpa_supplicant[373]: wlan0: CTRL-EVENT-EAP-STARTED EAP 
> authentication started
> Aug 12 21:04:22  wpa_supplicant[373]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD 
> vendor=0 method=13 -> NAK
> Aug 12 21:04:22  wpa_supplicant[373]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD 
> vendor=0 method=25
> Aug 12 21:04:22  wpa_supplicant[373]: wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 
> 0 method 25 (PEAP) selected
> Aug 12 21:04:23  wpa_supplicant[373]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=2 
> subject='/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 
> VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary 
> Certification Authority - G5' 
> hash=8420dfbe376f414bf4c0a81e6936d24ccc03f304835b86c7a39142fca723a689
> Aug 12 21:04:23  wpa_supplicant[373]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 
> s

Re: Panic in stable/11 (amd64) @r303903: page fault while in kernel mode

[Adrian Chadd]

EIther stable/11 or head. Both are fine.



-a


On 12 August 2016 at 11:05, David Wolfskill <da...@catwhisker.org> wrote:
> On Fri, Aug 12, 2016 at 11:01:25AM -0700, Adrian Chadd wrote:
>> David,
>>
>> Totally untested; will need manual application as I bet this patch is 
>> mangled.
>>
>> Would you mind testing this? I have a feeling we need to add if_addr
>> lock calls in a few places.
>
> Sure; I'll test.  Which branch?
>
> Please note that "lack of recurrence" of the panic isn't especially
> indiciative, as I hadn't seen it previously or since.  (Then again,
> yestrday & today, I've been using the wired NIC on the laptop while I'm
> at work, as the laptop has been unable to get a DHCP lease here.  (It
> worked OK at Hacker Dojo last night, and works OK at home.)
>
>> Thanks,
>>
>>
>> -adrian
>> 
>
> :-)
>
> Peace,
> david
> --
> David H. Wolfskill  da...@catwhisker.org
> Those who would murder in the name of God or prophet are blasphemous cowards.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
___
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: Panic in stable/11 (amd64) @r303903: page fault while in kernel mode

[Adrian Chadd]

David,

Totally untested; will need manual application as I bet this patch is mangled.

Would you mind testing this? I have a feeling we need to add if_addr
lock calls in a few places.

Thanks,


-adrian

Index: sys/net80211/ieee80211_ioctl.c
===
--- sys/net80211/ieee80211_ioctl.c (revision 303738)
+++ sys/net80211/ieee80211_ioctl.c (working copy)
@@ -3389,15 +3389,16 @@
  /* Wait for parent ioctl handler if it was queued */
  if (wait) {
  ieee80211_waitfor_parent(ic);
-
  /*
  * Check if the MAC address was changed
  * via SIOCSIFLLADDR ioctl.
  */
+ if_addr_rlock(ifp);
  if ((ifp->if_flags & IFF_UP) == 0 &&
  !IEEE80211_ADDR_EQ(vap->iv_myaddr, IF_LLADDR(ifp)))
  IEEE80211_ADDR_COPY(vap->iv_myaddr,
  IF_LLADDR(ifp));
+ if_addr_runlock(ifp);
  }
  break;
  case SIOCADDMULTI:
___
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: SO_BINDANY in FreeBSD 10.3

[Adrian Chadd]

Yeah, I integrated them from you like 10 years ago. It's in there somewhere. :-)

(IP_BINDANY?)

https://groups.google.com/forum/#!topic/mailing.freebsd.ipfw/L8lzLmG05WE

.. poke me to write up some documentation. :)

-adrian

On 12 August 2016 at 08:29, Julian Elischer  wrote:
> On 12/08/2016 8:00 PM, Alex Povolotsky wrote:
>>
>> Hello
>>
>> Is SO_BINDANY supported in FreeBSD 10.3? If not, do any patches exists?
>
> I'm certain that it is, somehow, but I'll be damned if I can remember how to
> do it..
> There were patches for it in the 90s and early 2000s but I seem to remember
> they were integrated into the system.
> I think it had a different name though.
>
>
>>
>> Alex
>> ___
>> 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"

Re: Panic in stable/11 (amd64) @r303903: page fault while in kernel mode

[Adrian Chadd]

[snip]

#define IF_LLADDR(ifp)  \
LLADDR((struct sockaddr_dl *)((ifp)->if_addr->ifa_addr))


it's because if_addr is NULL in your dump. God knows why that is! My
guess is we caught it in some stupid update window.

Ok, so what should we do for locking?



-adrian


signature.asc
Description: PGP signature
___
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: Unstable local network throughput

[Adrian Chadd]

Which ones of these hit the line rate comfortably?



-a


On 11 August 2016 at 15:35, Ben RUBSON <ben.rub...@gmail.com> wrote:
>
>> On 11 Aug 2016, at 18:36, Adrian Chadd <adrian.ch...@gmail.com> wrote:
>>
>> Hi!
>>
>> mlx4_core0:  mem
>> 0xfbe0-0xfbef,0xfb00-0xfb7f irq 64 at device 0.0
>> numa-domain 1 on pci16
>> mlx4_core: Initializing mlx4_core: Mellanox ConnectX VPI driver v2.1.6
>> (Aug 11 2016)
>>
>> so the NIC is in numa-domain 1. Try pinning the worker threads to
>> numa-domain 1 when you run the test:
>>
>> numactl -l first-touch-rr -m 1 -c 1 ./test-program
>>
>> You can also try pinning the NIC threads to numa-domain 1 versus 0 (so
>> the second set of CPUs, not the first set.)
>>
>> vmstat -ia | grep mlx (get the list of interrupt thread ids)
>> then for each:
>>
>> cpuset -d 1 -x 
>>
>> Run pcm-memory.x each time so we can see the before and after effects
>> on local versus remote memory access.
>>
>> Thanks!
>
> Adrian, here are the results :
>
>
>
> Idle system :
> http://pastebin.com/raw/K1iMVHVF
>
>
>
> No pinning :
> http://pastebin.com/raw/w5KuexQ3
> CPU : http://pastebin.com/raw/8zgRaazN
>
> numactl -l fixed-domain-rr -m 1 -c 1 :
> http://pastebin.com/raw/VWweYF9H
> CPU : http://pastebin.com/raw/QjaVH32X
>
> numactl -l fixed-domain-rr -m 0 -c 0 :
> http://pastebin.com/raw/71hfGJdw
> CPU : http://pastebin.com/raw/hef058Na
>
> numactl -l fixed-domain-rr -m 1 -c 1
> + cpuset -l  -x  :
> http://pastebin.com/raw/nEQkgMK2
> CPU : http://pastebin.com/raw/R652KAdJ
>
> numactl -l fixed-domain-rr -m 0 -c 0
> + cpuset -l  -x  :
> http://pastebin.com/raw/GdYJHyae
> CPU : http://pastebin.com/raw/Ggfx9uF9
>
>
>
> No pinning, default kernel (no NUMA option) :
> http://pastebin.com/raw/iQ2u8d8k
> CPU : http://pastebin.com/raw/Xr77KpcM
>
> default kernel (no NUMA option)
> + cpuset -l 
> + cpuset -l  -x  :
> http://pastebin.com/raw/VBWg4SZs
>
> default kernel (no NUMA option)
> + cpuset -l 
> + cpuset -l  -x  :
> http://pastebin.com/raw/SrJLZxuT
>
>
>
> No pinning, default kernel (no NUMA option), NUMA BIOS disabled :
> http://pastebin.com/raw/P5LrUASN
>
>
>
> I would say :
> - FreeBSD <= 10.3 : disable NUMA in BIOS
> - FreeBSD >= 11   : disable NUMA in BIOS or enable NUMA in kernel.
> But let's wait your analysis :)
>
>
>
> Ben
>
> ___
> 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"

Re: Unstable local network throughput

[Adrian Chadd]

adrian did mean fixed-domain-rr. :-P sorry!

(Sorry, needed to update my NUMA boxes, things "changed" since I wrote this.)


-a
___
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: Unstable local network throughput

[Adrian Chadd]

Hi!

mlx4_core0:  mem
0xfbe0-0xfbef,0xfb00-0xfb7f irq 64 at device 0.0
numa-domain 1 on pci16
mlx4_core: Initializing mlx4_core: Mellanox ConnectX VPI driver v2.1.6
(Aug 11 2016)

so the NIC is in numa-domain 1. Try pinning the worker threads to
numa-domain 1 when you run the test:

numactl -l first-touch-rr -m 1 -c 1 ./test-program

You can also try pinning the NIC threads to numa-domain 1 versus 0 (so
the second set of CPUs, not the first set.)

vmstat -ia | grep mlx (get the list of interrupt thread ids)
then for each:

cpuset -d 1 -x 

Run pcm-memory.x each time so we can see the before and after effects
on local versus remote memory access.

Thanks!



-adrian
___
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: Unstable local network throughput

[Adrian Chadd]

On 10 August 2016 at 12:50, Ben RUBSON <ben.rub...@gmail.com> wrote:
>
>> On 10 Aug 2016, at 21:47, Adrian Chadd <adrian.ch...@gmail.com> wrote:
>>
>> hi,
>>
>> yeah, I'd like you to do some further testing with NUMA. Are you able
>> to run freebsd-11 or -HEAD on these boxes?
>
> Hi Adrian,
>
> Yes I currently have 11 BETA3 running on them.
> I could also run BETA4.

hi,

ok, lets start by getting the NUMA bits into the kernel so you can
mess with things.

add this to the kernel

options MAXMEMDOM=8
(which hopefully is enough)
options VM_NUMA_ALLOC
options DEVICE_NUMA

Then reboot and post your 'dmesg' output to the list. This should show
exactly which domain devices are in.

Install the 'intel-pcm' package. There's a 'pcm-numa.x' command - do
kldload cpuctl, then run pcm-numa.x and see if it works. It should
give us some useful information about NUMA.
(Same as pcm-memory.x, pcm-pcie.x, etc.)

Then next is playing around with interrupt thread / userland cpuset
and memory affinity. We can look at that next. Currently the kernel
doesn't know about NUMA local memory for device driver memory, kernel
allocations for mbufs, etc, but we should still get a "good enough"
idea about things. We can talk about that here once the above steps
are done.

Thanks!



-adrian
___
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: Unstable local network throughput

[Adrian Chadd]

hi,

yeah, I'd like you to do some further testing with NUMA. Are you able
to run freebsd-11 or -HEAD on these boxes?


-adrian


On 8 August 2016 at 07:01, Ben RUBSON  wrote:
>
>> On 04 Aug 2016, at 11:40, Ben RUBSON  wrote:
>>
>>
>>> On 02 Aug 2016, at 22:11, Ben RUBSON  wrote:
>>>
 On 02 Aug 2016, at 21:35, Hans Petter Selasky  wrote:

 The CX-3 driver doesn't bind the worker threads to specific CPU cores by 
 default, so if your CPU has more than one so-called numa, you'll end up 
 that the bottle-neck is the high-speed link between the CPU cores and not 
 the card. A quick and dirty workaround is to "cpuset" iperf and the 
 interrupt and taskqueue threads to specific CPU cores.
>>>
>>> My CPUs : 2x E5-2620v3 with DDR4@1866.
>>
>> OK, so I cpuset all Mellanox interrupts to one NUMA, as well as the iPerf 
>> processes, and I'm able to reach max bandwidth.
>> Choosing the wrong NUMA (or both, or one for interrupts, the other one for 
>> iPerf, etc...) totally kills throughput.
>>
>> However, full-duplex throughput is still limited, I can't manage to reach 
>> 2x40Gb/s, throttle is at about 45Gb/s.
>> I tried many different cpuset layouts, but I never went above 45Gb/s.
>> (Linux allowed me to reach 2x40Gb/s so hardware is not a bottleneck)
>
> OK, I then found a workaround.
>
> In the motherboards' BIOS, I disabled the following option :
> Advanced / ACPI Settings / NUMA
>
> And I'm now able to go up to 2x40Gb/s !
> I'm then even able to achieve this throughput without any cpuset !
>
> Strange that Linux was able to deal with this setting, but I'm pretty sure 
> production performance will be easier to maintain with only 1 NUMA.
>
> Feel free to ask me if you want further testing with 2 NUMA.
>
> Ben
>
> ___
> 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"

Re: proposal: splitting NIC RSS up from stack RSS

[Adrian Chadd]

On 7 August 2016 at 18:40, Sepherosa Ziehau <sepher...@gmail.com> wrote:
> On Thu, Aug 4, 2016 at 3:55 PM, Adrian Chadd <adr...@freebsd.org> wrote:
>> [snip]
>>
>> I've updated the wiki with this TODO list. How's it look?
>>
>> https://wiki.freebsd.org/NetworkRSS
>
> Pretty much what had been discussed on the mail-list.  Good summary.

Cool, thanks.

I'd like to talk about this and whatever other networking-y things
people would like to try and land at -12 at meetbsd this year. Please
let me know if you're interested in this.


-adrian

>
> Thanks,
> sephe
>
> --
> Tomorrow Will Never Die
___
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: proposal: splitting NIC RSS up from stack RSS

[Adrian Chadd]

[snip]

I've updated the wiki with this TODO list. How's it look?

https://wiki.freebsd.org/NetworkRSS


-adrian
___
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: proposal: splitting NIC RSS up from stack RSS

[Adrian Chadd]

On 21 July 2016 at 18:54, Sepherosa Ziehau <sepher...@gmail.com> wrote:
> On Fri, Jul 22, 2016 at 6:39 AM, Adrian Chadd <adr...@freebsd.org> wrote:
>> hi,
>>
>> Cool! Yeah, the RSS bits thing can be removed, as it's just doing a
>> bitmask instead of a % operator to do mapping. I think we can just go
>> to % and if people need the extra speed from a power-of-two operation,
>> they can reintroduce it.
>
> I thought about it a while ago (the most popular E5-2560v{1,2,3} only
> has 6 cores, but E5-2560v4 has 8 cores! :).  Since the raw RSS hash
> value is '& 0x1f' (I believe most of the NICs use 128 entry indirect
> table as defined by MS RSS) to select an entry in the indirect table,
> simply '%' on the raw RSS hash value probably will not work properly;
> you will need (hash&0x1f)%mp_ncpus at least.  And well, since the
> indirect table's size if 128, you still will get some uneven CPU
> workload for non-power-of-2 cpus.  And if you take cpu affinity into
> consideration, the situation will be even more complex ...

Hi,

Sure. The biggest annoying part is that a lot of the kernel
infrastructure for queueing packets (netisr) and scheduling stack work
(callouts) are indexed on CPU, not on "thing". If it was indexed on
"thing" then we could do a two stage work redistribution method that'd
scale O(1):

* packets get plonked into "thing" via some mapping table - eg, map
128 or 256 buckets to queues that do work / schedule call outs /
netisr; and
* the queues aren't tied to a CPU at this point, and it can get
shuffled around by using cpumasks.

It'd be really, really nice IMHO if we had netisr and callouts be
"thing" based rather than "cpu" based, so we could just shift work by
changing the CPU mask - then we don't have to worry about rescheduling
packets or work onto the new CPU when we want to move load around.
That doesn't risk out of order packet handling behaviour and it means
we can (in theory!) put a given RSS bucket into more than one CPU, for
things like TCP processing.

Trouble is, this is somewhat contentious. I could do the netisr change
without upsetting people, but the callout code honestly makes me want
to set everything (in sys/kern) on fire and start again. After all of
the current issues with the callout subsystem I kind of just want to
see hps finish his work and land it into head, complete with more
sensible lock semantics, before I look at breaking it out to not be
per-CPU based but instead allow subsystems to create their own worker
pools for callouts. I'm sure NFS and CAM would like this kind of thing
too.

Since people have asked me about this in the past, the side effect of
support dynamic hash mapping (even in software) is that for any given
flow, once you change the hash mapping you will have some packets in
said flow in the old queue and some packets in the new queue. For
things like stack TCP/UDP where it's using pcbgroups it can vary from
being slow to (eventually, when the global list goes away) plainly not
making it to the right pcb/socket, which is okay for some workloads
and not for others. That may be a fun project to work on once the
general stack / driver tidyups are done, but I'm going to resist doing
it myself for a while because it'll introduce the above uncertainties
which will cause out-of-order behaviour that'll likely generate more
problem reports than I want to handle.

(Read: since I'm doing this for free, I'm not going to do anything
risky, as I'm not getting paid to wade through the repercussions just
right now.)

FWIW, we had this same problem in ye olde past with squid and WCCP
with its hash based system. Squid's WCCP implementation was simple and
static. The commercial solutions (read: cisco, etc) implemented
handling the cache set changing / hash traffic map changing by having
the caches redirect traffic to the /old/ cache whenever the hash or
cache set changed. Squid didn't do this out of the box, so if the
cache topology changed it would send traffic to the wrong box and the
existing connections would break.



-adrian
___
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: proposal: splitting NIC RSS up from stack RSS

[Adrian Chadd]

hi,

Cool! Yeah, the RSS bits thing can be removed, as it's just doing a
bitmask instead of a % operator to do mapping. I think we can just go
to % and if people need the extra speed from a power-of-two operation,
they can reintroduce it.

I'll add that to the list.

There's a librss, I don't think I committed it to -HEAD. I'll go dig
it out and throw it into freebsd-head soon.



-adrian
___
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"

proposal: splitting NIC RSS up from stack RSS

[Adrian Chadd]

Hi,

now that 11 is branched and marching on, I'd like to start pushing
some more improvements/evolution into the RSS side of things.

The short list feedback from people is:

* it'd be nice to be able to configure per-device RSS keys on the fly;
* it'd be nice to be able to configure per-device RSS bucket mappings
on the fly;
* it'd be nice to be able to configure per-device RSS hash
configurations on the fly;
* it'd be nice to be able to configure per-bucket CPU set mappings on the fly;
* it'd be nice to split the RSS driver side, the RSS packet input side
and the RSS stack side of things up into separate options;
* UDP IPv6 RSS support would be nice (it works, but i need to
test/integrate bz's v6 udp locking changes for it to really matter);
* it'd be nice to scale linearly on incoming /and/ outgoing
connections. Right now incoming connections are easy, but outgoing
connections aren't so easy.

The other big thing, mostly to be expected, is:

* it'd be nice if this were better documented;
* it'd be nice if we had easy examples of this stuff working, complete
with library bits in base.

I'm going to tidy up the NetworkRSS bits in the wiki soon and map out
a roadmap for 12 with some other bits and pieces.

The "can we have RSS for NICs but not for the stack, and have
keys/mapping/bucket configurable" is actually a biggish thing, as that
ties into people wanting to abuse things with netmap. They don't care
about the rest of the stack being RSS aware; they just want to be able
to control the NIC configurations from userspace and then get it
completely out of the way.

I'd appreciate any other feedback/comments/suggestions. If you're
using RSS and you haven't told me then please let me know!

thanks,


-adrian
___
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: panic with tcp timers

[Adrian Chadd]

There's implications for RSS with how the callout system currently works.

If you don't know the RSS bucket ID of a connection in advance, you'll
create callouts on the wrong CPUs and then they're not migrated.

The initial work here did convert things over, but didn't place the
callouts in the right CPU/RSS bucket and there wasn't a mechanism to
fix this. :(

(But I'm also a firm believer of that too. I'd also finally just like
the callout system to not be tied to per-CPU queues, but also
per-RSS-bucket callout wheels so we could assign a CPU mask to a given
callout wheel and then migrating things around is just "change cpu
mask", not "change callout cpu id.")


-adrian


On 20 June 2016 at 04:00, Hans Petter Selasky  wrote:
> On 06/20/16 12:30, Gleb Smirnoff wrote:
>>
>> What does prevent us from converting TCP timeouts to locked? To my
>> understanding it is the lock order of taking pcbinfo after pcb lock.
>
>
> I started this work:
>
> https://reviews.freebsd.org/D1563
>
> --HPS
> ___
> 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"

Re: Is DWA-131 rev E1 WiFi dongle supported yet?

[Adrian Chadd]

Hi,

Kevin hasn't finished / integrated the support yet, sorry :(



-adrian


On 18 May 2016 at 17:49, Mateusz Piotrowski <0...@freebsd.org> wrote:
> Hi,
>
> According to this thread 
> (https://lists.freebsd.org/pipermail/freebsd-arm/2015-December/012935.html 
> ) 
> DWA-131 revision E1 (rtl8192eu) is not supported by FreeBSD.
>
> Has anything changed so far? Is this WiFi dongle going to be supported 
> anytime soon?
>
> I wasn’t able to find any recent information about it.
>
> Cheers!
>
> Mateusz Piotrowski
> ___
> 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"

Re: [FreeBSD 10-3] undefined reference to getsourcefilter /setsourcefilter

[Adrian Chadd]

Some extern "C" { } around some includes? :)


-a


On 8 May 2016 at 14:46, Victor Toni  wrote:
> Trying to port mcproxy to FreeBSD I encountered a quite strange problem.
> Compiling everything works but linking fails with the following error:
>
> $ c++ -v -Wl,-rpath,/usr/local/lib -pthread -o mcproxy main.o
>  hamcast_logging.o  mc_socket.o  addr_storage.o  mroute_socket.o  if_prop.o
>  reverse_path_filter.o  proxy.o  sender.o  receiver.o  mld_receiver.o
>  igmp_receiver.o  mld_sender.o  igmp_sender.o  proxy_instance.o  routing.o
>  worker.o  timing.o  check_if.o  check_kernel.o  membership_db.o  querier.o
>  timers_values.o  interfaces.o  def.o  simple_mc_proxy_routing.o
>  simple_routing_data.o  scanner.o  token.o  configuration.o  parser.o
>  interface.o-L/usr/local/lib -L/usr/lib -lpthread
> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
> Target: i386-unknown-freebsd10.3
> Thread model: posix
> Selected GCC installation:
>  "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1
> --hash-style=both --enable-new-dtags -m elf_i386_fbsd -o mcproxy
> /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/local/lib
> -L/usr/lib -L/usr/lib -rpath /usr/local/lib main.o hamcast_logging.o
> mc_socket.o addr_storage.o mroute_socket.o if_prop.o reverse_path_filter.o
> proxy.o sender.o receiver.o mld_receiver.o igmp_receiver.o mld_sender.o
> igmp_sender.o proxy_instance.o routing.o worker.o timing.o check_if.o
> check_kernel.o membership_db.o querier.o timers_values.o interfaces.o def.o
> simple_mc_proxy_routing.o simple_routing_data.o scanner.o token.o
> configuration.o parser.o interface.o -lpthread -lc++ -lm -lgcc --as-needed
> -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s
> --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
> mc_socket.o: In function `mc_socket::set_source_filter(unsigned int,
> addr_storage const&, unsigned int, std::__1::list std::__1::allocator > const&) const':
> src/utils/mc_socket.cpp:(.text+0x29cc): undefined reference to
> `setsourcefilter(int, unsigned int, sockaddr*, unsigned int, unsigned int,
> unsigned int, sockaddr_storage*)'
> mc_socket.o: In function `mc_socket::get_source_filter(unsigned int,
> addr_storage const&, unsigned int&, std::__1::list std::__1::allocator >&) const':
> src/utils/mc_socket.cpp:(.text+0x2c29): undefined reference to
> `getsourcefilter(int, unsigned int, sockaddr*, unsigned int, unsigned int*,
> unsigned int*, sockaddr_storage*)'
> src/utils/mc_socket.cpp:(.text+0x2cae): undefined reference to
> `getsourcefilter(int, unsigned int, sockaddr*, unsigned int, unsigned int*,
> unsigned int*, sockaddr_storage*)'
> c++: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> The methods should be found:
>
> $ readelf -s /usr/lib/libc.a | grep etsourcefilter
> 10: 0600   392 FUNCGLOBAL DEFAULT1 getsourcefilter
> 12: 0290   305 FUNCGLOBAL DEFAULT1 setsourcefilter
>
>
> What am I missing?
> ___
> 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"

Re: netmap overrun counters

[Adrian Chadd]

It doesn't overwrite unread slots; it just hits the end and stops
RX'ing (and is counted by the NIC as an RX overflow) until you've
RX'ed some frames and told netmap what you've handed.


-adrian
___
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"

[Differential] [Accepted] D5318: hyperv/hn: Free the txdesc buf_ring when the TX ring is destroyed

[adrian (Adrian Chadd)]

adrian accepted this revision.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D5318

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-virtualization-list, freebsd-net-list
___
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"

[Differential] [Accepted] D5317: hyperv/hn: Enable IP header checksum offloading for WIN8 (WinServ2012)

[adrian (Adrian Chadd)]

adrian accepted this revision.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D5317

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-virtualization-list, freebsd-net-list
___
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"

[Differential] [Accepted] D5316: hyperv/hn: Add option to bind TX taskqueues to the specified CPU

[adrian (Adrian Chadd)]

adrian accepted this revision.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D5316

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-virtualization-list, freebsd-net-list
___
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"

[Differential] [Accepted] D5276: hyperv/hn: Use taskqueue_enqueue()

[adrian (Adrian Chadd)]

adrian accepted this revision.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D5276

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-virtualization-list, freebsd-net-list
___
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"

[Differential] [Accepted] D5275: hyperv/hn: Split RX ring data structure out of softc

[adrian (Adrian Chadd)]

adrian accepted this revision.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D5275

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-virtualization-list, freebsd-net-list
___
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"

[Differential] [Accepted] D5290: hyperv/hn: Use buf_ring for txdesc list

[adrian (Adrian Chadd)]

adrian accepted this revision.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D5290

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-virtualization-list, freebsd-net-list
___
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"

[Differential] [Accepted] D5272: hyperv/hn: Add option to allow sharing TX taskq between hn instances

[adrian (Adrian Chadd)]

adrian accepted this revision.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D5272

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-virtualization-list, freebsd-net-list
___
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"

[Differential] [Accepted] D5274: hyperv/hn: Change global tunable prefix to hw.hn

[adrian (Adrian Chadd)]

adrian accepted this revision.

REVISION DETAIL
  https://reviews.freebsd.org/D5274

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
howard0su_gmail.com, honzhan_microsoft.com, adrian, network
Cc: freebsd-virtualization-list, freebsd-net-list
___
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"

[Differential] [Accepted] D5273: hyperv/hn: Always do transmission scheduling.

[adrian (Adrian Chadd)]

adrian accepted this revision.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D5273

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-virtualization-list, freebsd-net-list
___
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"

[Differential] [Accepted] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

[adrian (Adrian Chadd)]

adrian accepted this revision.

REVISION DETAIL
  https://reviews.freebsd.org/D5185

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, np, transport, hselasky, gallatin, 
adrian, network
Cc: freebsd-virtualization-list, freebsd-net-list
___
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"

[Differential] [Accepted] D5283: hyperv/hn: Split TX ring data structure out of softc

[adrian (Adrian Chadd)]

adrian accepted this revision.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D5283

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-virtualization-list, freebsd-net-list
___
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"

[Differential] [Accepted] D5282: hyperv/hn: Use non-fast taskqueue for transmission

[adrian (Adrian Chadd)]

adrian accepted this revision.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D5282

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-virtualization-list, freebsd-net-list
___
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"

[Differential] [Accepted] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

[adrian (Adrian Chadd)]

adrian accepted this revision.
adrian added a comment.


  Nice! Thanks for all this work!

REVISION DETAIL
  https://reviews.freebsd.org/D5185

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, hselasky, np, transport, gallatin, 
adrian, network
Cc: freebsd-virtualization-list, freebsd-net-list
___
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"

[Differential] [Commented On] D5185: tcp/lro: Allow network drivers to set the limit for TCP ACK/data segment aggregation limit

[adrian (Adrian Chadd)]

adrian added inline comments.

INLINE COMMENTS
  sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c:455 this should be a separate 
commit

REVISION DETAIL
  https://reviews.freebsd.org/D5185

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, network, adrian, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, hselasky, np, transport, gallatin
Cc: freebsd-virtualization-list, freebsd-net-list
___
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: ixgbe: Network performance tuning (#TCP connections)

[Adrian Chadd]

hi,

can you share your testing program source?


-a


On 3 February 2016 at 05:37, Meyer, Wolfgang  wrote:
> Hello,
>
> we are evaluating network performance on a DELL-Server (PowerEdge R930 with 4 
> Sockets, hw.model: Intel(R) Xeon(R) CPU E7-8891 v3 @ 2.80GHz) with 10 
> GbE-Cards. We use programs that on server side accepts connections on a 
> IP-address+port from the client side and after establishing the connection 
> data is sent in turns between server and client in a predefined pattern 
> (server side sends more data than client side) with sleeps in between the 
> send phases. The test set-up is chosen in such way that every client process 
> initiates 500 connections handled in threads and on the server side each 
> process representing an IP/Port pair also handles 500 connections in threads.
>
> The number of connections is then increased and the overall network througput 
> is observed using nload. On FreeBSD (on server side) roughly at 50,000 
> connections errors begin to occur and the overall throughput won't increase 
> further with more connections. With Linux on the server side it is possible 
> to establish more than 120,000 connections and at 50,000 connections the 
> overall throughput ist double that of FreeBSD with the same sending pattern. 
> Furthermore system load on FreeBSD is much higher with 50 % system usage on 
> each core and 80 % interrupt usage on the 8 cores handling the interrupt 
> queues for the NIC. In comparison Linux has <10 % system usage, <10 % user 
> usage and about 15 % interrupt usage on the 16 cores handling the network 
> interrupts for 50,000 connections.
>
> Varying the numbers for the NIC interrupt queues won't change the performance 
> (rather worsens the situation). Disabling Hyperthreading (utilising 40 cores) 
> degrades the performance. Increasing MAXCPU to utilise all 80 cores won't 
> improve compared to 64 cores, atkbd and uart had to be disabled to avoid 
> kernel panics with increased MAXCPU (thanks to Andre Oppermann for 
> investigating this). Initiallly the tests were made on 10.2 Release, later I 
> switched to 10 Stable (later with ixgbe driver version 3.1.0) but that didn't 
> change the numbers.
>
> Some sysctl configurables were modified along the network performance 
> guidelines found on the net (e.g. 
> https://calomel.org/freebsd_network_tuning.html, 
> https://www.freebsd.org/doc/handbook/configtuning-kernel-limits.html, 
> https://pleiades.ucsc.edu/hyades/FreeBSD_Network_Tuning) but most of them 
> didn't have any measuarable impact. Final sysctl.conf and loader.conf 
> settings see below. Actually the only tunables that provided any improvement 
> were identified to be hw.ix.txd, and hw.ix.rxd that were reduced (!) to the 
> minimum value of 64 and hw.ix.tx_process_limit and hw.ix.rx_process_limit 
> that were set to -1.
>
> Any ideas what tunables might be changed to get a higher number of TCP 
> connections (it's not a question of the overall throughput as changing the 
> sending pattern allows me to fully utilise the 10Gb bandwidth)? How can I 
> determine where the kernel is spending its time that causes the high CPU 
> load? Any pointers are highly appreciated, I can't believe that there is such 
> a blatant difference in network performance compared to Linux.
>
> Regards,
> Wolfgang
>
> :
> cc_htcp_load="YES"
> hw.ix.txd="64"
> hw.ix.rxd="64"
> hw.ix.tx_process_limit="-1"
> hw.ix.rx_process_limit="-1"
> hw.ix.num_queues="8"
> #hw.ix.enable_aim="0"
> #hw.ix.max_interrupt_rate="31250"
>
> #net.isr.maxthreads="16"
>
> :
> kern.ipc.soacceptqueue=1024
>
> kern.ipc.maxsockbuf=16777216
> net.inet.tcp.sendbuf_max=16777216
> net.inet.tcp.recvbuf_max=16777216
>
> net.inet.tcp.tso=0
> net.inet.tcp.mssdflt=1460
> net.inet.tcp.minmss=1300
>
> net.inet.tcp.nolocaltimewait=1
> net.inet.tcp.syncache.rexmtlimit=0
>
> #net.inet.tcp.syncookies=0
> net.inet.tcp.drop_synfin=1
> net.inet.tcp.fast_finwait2_recycle=1
>
> net.inet.tcp.icmp_may_rst=0
> net.inet.tcp.msl=5000
> net.inet.tcp.path_mtu_discovery=0
> net.inet.tcp.blackhole=1
> net.inet.udp.blackhole=1
>
> net.inet.tcp.cc.algorithm=htcp
> net.inet.tcp.cc.htcp.adaptive_backoff=1
> net.inet.tcp.cc.htcp.rtt_scaling=1
>
> net.inet.ip.forwarding=1
> net.inet.ip.fastforwarding=1
> net.inet.ip.rtexpire=1
> net.inet.ip.rtminexpire=1
>
>
>
>
> 
>
> Follow HOB:
>
> - HOB: http://www.hob.de/redirect/hob.html
> - Xing: http://www.hob.de/redirect/xing.html
> - LinkedIn: http://www.hob.de/redirect/linkedin.html
> - HOBLink Mobile: http://www.hob.de/redirect/hoblinkmobile.html
> - Facebook: http://www.hob.de/redirect/facebook.html
> - Twitter: http://www.hob.de/redirect/twitter.html
> - YouTube: http://www.hob.de/redirect/youtube.html
> - E-Mail: http://www.hob.de/redirect/mail.html
>
>
> HOB GmbH & Co. KG
> Schwadermuehlstr. 3
> D-90556 Cadolzburg
>
> Geschaeftsfuehrung: Klaus Brandstaetter, Zoran Adamovic
>
> AG Fuerth, HRA 5180
> Steuer-Nr. 

[Differential] [Accepted] D5175: hyperv/hn: Add an option to always do transmission scheduling

[adrian (Adrian Chadd)]

adrian accepted this revision.
adrian added a comment.
This revision has a positive review.


  Fine by me!

REVISION DETAIL
  https://reviews.freebsd.org/D5175

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-virtualization-list, freebsd-net-list
___
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"

[Differential] [Accepted] D5103: hyperv/hn: Add sysctl to trust host side UDP and IP csum verification

[adrian (Adrian Chadd)]

adrian accepted this revision.
adrian added a comment.


  So this is okay, but we put the non-unit bits under 'hw', not 'dev'. Ie, it'd 
be dev.XXX.0.stuff, and hw.XXX.stuff.
  
  So I'll okay this, but we should eventually shuffle them back to 'hw'.

REVISION DETAIL
  https://reviews.freebsd.org/D5103

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
howard0su_gmail.com, honzhan_microsoft.com, adrian, network
Cc: freebsd-net-list
___
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"

[Differential] [Accepted] D5098: hyperv/hn: Reorganize TX csum offloading

[adrian (Adrian Chadd)]

adrian accepted this revision.
adrian added a comment.


  Good!

REVISION DETAIL
  https://reviews.freebsd.org/D5098

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
howard0su_gmail.com, honzhan_microsoft.com, adrian, network
Cc: freebsd-net-list
___
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"

[Differential] [Accepted] D5166: hyperv/hn: Increase LRO entry count to 128 by default

[adrian (Adrian Chadd)]

adrian accepted this revision.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D5166

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-net-list
___
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"

[Differential] [Accepted] D5159: hyperv/hn: Recover half of the chimney sending space

[adrian (Adrian Chadd)]

adrian accepted this revision.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D5159

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-net-list
___
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"

[Differential] [Accepted] D5167: hyperv/hn: Move LRO flush to the channel processing rollup

[adrian (Adrian Chadd)]

adrian accepted this revision.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D5167

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-net-list
___
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"

[Differential] [Accepted] D5158: hyperv/hn: Factor out hn_encap from hn_start_locked()

[adrian (Adrian Chadd)]

adrian accepted this revision.
This revision has a positive review.

REVISION DETAIL
  https://reviews.freebsd.org/D5158

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com, 
honzhan_microsoft.com, howard0su_gmail.com, adrian, network
Cc: freebsd-net-list
___
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: Chelsio T520-SO-CR low performance (netmap tested) for RX

[Adrian Chadd]

What are you doing for RX? More netmap? Or the normal stack?


-a


On 22 January 2016 at 21:34, Marcus Cenzatti  wrote:
> hello,
>
> I am testing a chelsio t520-so-cr connected to a Intel card with ix(4) 
> driver, I can get the ncxl0 interface to transmit at 14Mpps to another 
> chelsio or to a Intel card. However I can only get 800Kpps-1Mpps for RX tests 
> from both chelsio or Intel.
>
> I have test with both FreeBSD 11 and FreeBSD 10.3-PRERELEASE.
>
> I tested it untuned first and later I have applied tuning recommendations I 
> found on BSDRP[1] website. Results still ranging from 800Kpps to 1Mpps for RX.
>
> Tests are done w/ with pkt-gen in netmap mode on ncxl interface with both IP 
> address and MAC address source/dest.
>
> I have tested ix-ix and I can confirm 14Mpps for both RX and TX directions. I 
> have tested with two different chelsio T520 and both have the very same 
> results.
>
> What particular loader/sysctl or ifconfig options I should investigate?
>
> I also tested disabling txcsum, rxcsum and TSO. Results are different but 
> still on the much lower mentioned 800K-1M pps rate.
>
> thank you
>
> [1]http://bsdrp.net/documentation/examples/forwarding_performance_lab_of_a_hp_proliant_dl360p_gen8_with_10-gigabit_with_10-gigabit_chelsio_t540-cr
>
> ___
> 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"

Re: netmap design question - accessing netmap:X-n individual queues on FreeBSD

[Adrian Chadd]

For random src/dst ports and IPs and on the chelsio t5 40gig hardware,
I was getting what, uhm, 40mil tx pps and around 25ish mil rx pps?

The chelsio rx path really wants to be coalescing rx buffers, which
the netmap API currently doesn't support. I've no idea if luigi has
plans to add that. So, it has the hilarious side effect of "adding
more RX queues" translates to "drops in RX performance." :(

Thanks,

-a


On 23 January 2016 at 01:31, Pavel Odintsov <pavel.odint...@gmail.com> wrote:
> Hi!
>
> Great job! Do you have performance estimations?
>
>
> On Wednesday, 20 January 2016, Adrian Chadd <adrian.ch...@gmail.com> wrote:
>>
>> Ok, so, I mostly did this already:
>>
>> https://github.com/erikarn/netmap-tools/
>>
>> it has a multi-threaded, multi-queue bridge + ipv4 decap for testing.
>>
>>
>>
>> -a
>
>
>
> --
> Sincerely yours, Pavel Odintsov
___
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"