Going on vacation for a couple weeks, and will look at this again when I get back... adding adrian@ as a reviewer, feel free to add more appropriate reviewers as actionable feedback will be welcome when I return.

• Update manpage

• Add macros for TLV types

• Retry reset command up to twice.

Tested with Google Pixel Buds A... with virtual_oss, pairs and right channel works.

• Fix comment.

• Add to devd

So yeah, looks fine to me, but I'm very out of touch with current iflib, so I'm inclined to not approve with my iflib hat on. My biggest concern was that someone may think it's the right way to handle the bits.

Yeah, looks like em_if_update_admin_status() sets speed to zero when link is lost, so just not turning off TSO when speed == 0 would do the trick.

Wouldn't it also whack TSO on a flap for 1G? It seems like if you want TSO, you'll have to explicitly re-enable it every time a 1G link is established.

Ah yes, makes more sense to enable then... not sure how you'll manage to keep the admin preferences though. It looks like if I have TSO enabled and unplug the cable then plug it back in, TSO will become disabled?

Oh wow, so TSO works at 100Mbbs, but fails at 1Gbps? Crazy. I would personally be inclined to just disable TSO unconditionally in attach_pre(), but if someone *really* wants TSO for their "Fast" Ethernet connections, you may as well give it to them.

Add SOC_IMX6 to GENERIC since it's used in if_ffec.c now

I understand this will need to be split up, just wanted to get initial feedback in case I'm heading in terrible directions.

Clean up my cruft

Clean up my cruft

Clean up my cruft

Curious why the driver would need to change it in init... can devices actually change their supported offloads after attach? Aside from the initial setup, I would expect control of which offloads to use would be under the control of the user, not the driver... I would be very surprised if taking an interface down then up changed the offload flags.

Excellent news, and it looks like there's still some performance left on the table there. I guess the question now is if I consider the theory that getting rid of the mp ring improves performance proven and start gutting it, or if I finish separating the TX path from the reclaim path and clean this hack up more so further testing can be done.

So two things jump out at me here... first, a quick look suggests _task_fn_tx() -> iflib_txq_drain() is recursing on the mutex, and second the interrupt handler is contending with tx for no good reason.

Create a iflib_txq_drain_bypass() function called only from
iflib_if_transmit_bypass() which doesn't have the loop,
volatile/devolatile casts, conditional prefetching, txq-cast-to-mbuf,
etc overhead and only locks/unlocks once.

I assume the two piles in the bypass flamegraphs which don't start at fork_exit() are just because the stack sample isn't deep enough to correlate them over and that the iflib_txq_drain() samples in the wide peak are actually the ones that are directly in iflib_txq_drain?

For the bypass disabled results, is tx_abdicate set?

Use a tunable instead of a sysctl to toggle mp_ring bypass.

Wait... why is iflib_if_transmit() being called in both? It should be using iflib_if_transmit_bypass() instead.

Cannot reproduce with D20834 appplied.

Ping.

Ok, I didn't think these functions were hot enough to be worth optimizing, and I'm not sure anything can be optimized around E1000_WRITE_*

Phew, great job. I've always been a bit uneasy about the MSI/INTx stuff, but this seems to have cleared everything up.

Makes sense.

Use rtsdtr as the stty argument to set the default mode, and -rtsdtr to
disable automatically asserting them on open().

Address feedback, add support to umcs.

"Reference" count core offsets and free() when all drivers unloaded.

Fix style(), clean up default sysctl values, log message on malloc() failure.

In D20031#430635, @kevans wrote:

Tagging @ian as well, as he may be interested in this for $work purposes.

I think this also needs to cover the DTR|RTS setting in ucom_open (^/sys/dev/usb/serial/usb_serial.c) for completeness sake, but I defer to @imp and @ian as they've likely got better intuition of how that should work.

I'd really like to see this part split out into a separate review and committed soon, because it shouldn't see any contention- it adds control that is desirable to the people that know they need it, and doesn't really affect anyone else.

Looks good to me.

And again now that I've joined iflib...

Accepted. (derp)

LGTM

style(9) nits.

FILTER_SCHEDULE_THREAD is a flag, not a discrete value. If it's set, schedule the
gtask and return FILTER_HANDLED.

Return FILTER_HANDLED rather than FILTER_SCHEDULE_THREAD when gtask (potentially) scheduled
per @waddlesplash_gmail.com.

Some bits of the upstream patch didn't paply cleanly... added manually.

Put the result variable back in. *facepalm*

Unpack the conditional for easier reading.

Remove unrelated stuff.