also glebius poke me on irc. I'll go see if I need to rejoin various channels when I get to work. I just updated my freebsd-head testing boxes so I can throw this on a few wifi nics and test..

i can test out epoch wrapping around the net80211 stuff but should this be done at the driver level too? The wifi drivers tend to process bursts of frames in a deferred context..

I have no complaints; I'm still stuck on mips32r2 and similar non-SMP hardware for these router things. I'll soon be moving to ARM though..

In D19622#443714, @rscheff_gmx.at wrote:

@bz - once a packet (fragment in this case) has made it to it's destination, I would argue that you shouldn't needlessly drop that packet any more. (Host vs. Router behavior). An interface flapping frequently, and removing all enqueued fragments while doing this, would reduce the usability of such an interface from marginal to completely inoperable.
Using the ifp of the last received fragment rather the ifp of the initial one (in time, not relative offset) sounds to me like a good compromise.

hm, the iflib bits are already in -head?

I like this; but yeah we're going to need to add options iflib everywhere else to make the defaults work. Can you do that?

Hey this looks good! I don't have any hardware to test it on right now though so I'll take your word for it.

ooooh ok. yeah maybe we should add that CPU to the detected list?

ok, so can you add:

oh interesting. er, so i know this is asking a lot but I'm trying to understand explicitly what the hardware setup is.

so it turns out this isn't "right". There's already a way to configure the output function for the SoC side GPIO pins. look at the existing gpiofunc/gpiomode. That's what gpiofunc does (and gpiomode=1 just says "make it output, value low as a default"). It's only useful for AR934x and later.

looks good! i'll go commit it tonight.

In D20117#433281, @jhb wrote:

In D20117#433119, @gallatin wrote:

In D20117#433106, @adrian wrote:

I see you've done a bit of net80211 checking there; I think I'm going to use this change as motivation to speed up my desire to make rcvif manipulation a bit less insane and error prone.

Would it work to use PH_loc.ptr in place of rcvif to store the pointer the net80211 node struct? I assume PH_loc was added after you'd already taken rcvif?
If anybody wants to throw rotten vegetables for the choice to unionize rcvif and snd_tag, lob them at me. I argued strongly to keep the mbuf size unchanged. This is because (on amd64) we wind up taking an extra cacheline miss on mbuf ext free if the pkt_hdr adds a new pointer, because any additions to the packet header will push m_ext.ext_arg1 into another cacheline. In our workload, this ext_free happens millions of times per second. I wish I could think of some clean, non-intrusive way to have an mbuf have just an m_ext, but not waste space on a pkt_hdr.

I see you've done a bit of net80211 checking there; I think I'm going to use this change as motivation to speed up my desire to make rcvif manipulation a bit less insane and error prone.

In D20117#433053, @gallatin wrote:

In D20117#433037, @ae wrote:

I'm sorry, I completely missed this change in the past. But it looks like it can break ipfw firewall rules, since rcvif is now union with snd_tag. And this means, rcvif can be initialized for packets that were not actually received on specified interface. ipfw uses rcvif in rules to check that a packet was received on specified interface, and this check was correct even for outgoing packets. Now it looks like such checks can be incorrect.

Send tags are only used for endstation initiated traffic (eg, TCP). So if a packet has a send tag set, then it could not possibly have arrived via any interface. Eg, it would have previously had a NULL rcvif. So if you compare pointers, it should be fine.
If you look at something in the rcvif, there is now a flag (CSUM_SND_TAG) that indicates that the rcvif/snd_tag union is a send tag, so you can avoid treating a send_tag as an ifnet in that case.

I'm ok with flipping random on by default nowdays. There are bigger fish to fry in the "wasted kernel space" game.

I think this is a pretty self contained change and would like to see it land.

So in a Previous Project a Long Long Time Ago we solved this by having the receive/send state being an ifindex into an array of "ifnet" pointers, and a gencount so you can see if it's stale. Then all the code had to handle that the interface ifindex was stale (ie, a NULL pointer versus a garbage pointer) and decide at each point how to make forward progress. In some cases it wasn't needed for forward progress - eg it was already on a transmit queue, so the fact the receive interface went away wasn't a huge deal. But sometimes it was - eg tunnel (l2tp in one case) went away.

And yes I'd love for this to be addressed as a whole, but this is a pretty neat way to explicitly call out fixing up a good corner case.

*puts network engineer in the past hat on*

Yeah, we should have a fallback rate function in net80211.

Yeah please don't ifdef the structure definitions. I need to go do a pass at some point to make that not be a problem; it's 2018 :)

I was going to try and commit this to -head soon, as it's a pretty stand-alone thing. even just before -head branches.

This looks good! do you have commit privs or should I break it up into smaller pieces and commit it?

yaaaaayayaya do it~!

interesting! ok. I wonder how hard it'd be to integrate this into the existing ral driver. All of the RAL "HAL" routines right now really are almost complete drivers themselves with some shared bus management glue. HOw hard does it look to integrate it?

I think it's fine to extend it; longer SSIDs are now a thing and have been for a while.

It looks good! It'd be fun to try and RTS/CTS protect longer bursts, but that can always come later!

commit away! thanks!

commit away!

Replacing it with a placeholder bootstrap fortune shell script to retain backward compat is a smart move.

Approved.