In D41558#947392, @markj wrote:setting the ifdi_needs_restart default to false will alleviate the need to churn every driver if an odd event is added in the future for specific hardware.
Returning true by default seems like the safe default to me. Yes, unneeded reinits are annoying, but if we don't reinit when an event actually requires it, the result could be harder to debug.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Sep 21 2023
Sep 21 2023
Aug 24 2023
Aug 24 2023
Don't toggle vmxnet3
Sweep the drivers
Aug 23 2023
Aug 23 2023
Aug 22 2023
Aug 22 2023
Aug 18 2023
Aug 18 2023
Makes sense to me to get these in and continue the audit/additions
@bofh do you know if this was something you had to mark BROKEN or work around?
Aug 16 2023
Aug 16 2023
kbowling requested changes to D41480: sys/net: only panic on unset tx_csum_flags if cap is disabled.
What is triggering this for you?
kbowling added a comment to D40168: x11/nvidia-driver: Add Makefile.version and patch for nvidia-drm.
I see the optional assignment so I guess that part is fine. Ultimately it's not my port but if danfe is not going to comment I have no objections.
kbowling added a comment to D40168: x11/nvidia-driver: Add Makefile.version and patch for nvidia-drm.
It is not necessary to do it like this. There is an implied version contract with this port and x11/linux-nvidia-libs as well. If it is centralized, it needs to accommodate the entire nvidia-driver situation because this will cause build failures.
kbowling added a comment to D40168: x11/nvidia-driver: Add Makefile.version and patch for nvidia-drm.
I think you should remove the distversion thing, that will break the legacy ports and seems unnecessary.
Aug 13 2023
Aug 13 2023
@erj can you post the draft driver update, I'd like to see how it intends to use this patch stack before commentary
Aug 9 2023
Aug 9 2023
Aside from some research notes there is nothing to do here.
Aug 4 2023
Aug 4 2023
Jul 31 2023
Jul 31 2023
rebase after committed changes
Jul 29 2023
Jul 29 2023
@shurd updated automask to not require the iflib internal change.
I've found a way to do this without modifying iflib.
Jul 28 2023
Jul 28 2023
@shurd I added some smarts to the TSO automask. Also added a sysctl for people that want to opt out of.
Jul 27 2023
Jul 27 2023
kbowling added a comment to D41200: iflib: Move network stack capabilities after device driver init.
In D41200#938521, @shurd wrote: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.
kbowling added a comment to D41200: iflib: Move network stack capabilities after device driver init.
In D41200#938509, @shurd wrote: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?
kbowling added a comment to D41200: iflib: Move network stack capabilities after device driver init.
In D41200#938427, @shurd wrote: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.
Jul 26 2023
Jul 26 2023
kbowling added a comment to D41200: iflib: Move network stack capabilities after device driver init.
In D41200#938295, @shurd wrote: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.
Don't try TSO on 10/100 for lem(4)/em(4)
kbowling requested review of D41200: iflib: Move network stack capabilities after device driver init.
Jul 25 2023
Jul 25 2023
Jun 27 2023
Jun 27 2023
Jun 9 2023
Jun 9 2023
May 11 2023
May 11 2023
I think it's probably fine but can you elaborate situations where vlan 0 is "tagged"
May 8 2023
May 8 2023
Apr 29 2023
Apr 29 2023
Use a bool
Apr 25 2023
Apr 25 2023
Feb 9 2023
Feb 9 2023
Dec 20 2022
Dec 20 2022
Oct 17 2022
Oct 17 2022
kbowling added a comment to D34449: Allow em(4) to particpate in auto-negotiation for fixed 100b or 10b configuration.
The problem is what you submitted is logically inconsistent in the e1000 code. Other consumers of this code (i.e. Linux, DPDK) have not plugged the holes either (for the record they do not implement this improvement). I've provided a starting pointer in the phy code. You will find at least one more issue in the lem(4) phy code. This is via ripgrep and code inspection, you don't need any hardware to see it.
Oct 12 2022
Oct 12 2022
kbowling added a comment to D34449: Allow em(4) to particpate in auto-negotiation for fixed 100b or 10b configuration.
I can see where the "shared code" (e1000 api) is not ready in general and for lem(4). For the submitter, if you want to try and chase that down e1000_setup_copper_link_generic() in e1000_phy.c.. maybe try modifying the conditional. I'm going to revert this.
Oct 10 2022
Oct 10 2022
Jun 22 2022
Jun 22 2022
May 15 2022
May 15 2022
May 10 2022
May 10 2022
May 4 2022
May 4 2022
Apr 19 2022
Apr 19 2022
Apr 13 2022
Apr 13 2022
Committed as 395cc55d8966
Committed as 07ede751612f
kbowling accepted D34449: Allow em(4) to particpate in auto-negotiation for fixed 100b or 10b configuration.
I think hw->phy.autoneg_wait_to_complete is also set to false in the driver earlier in em_if_attach_pre() and never changes.
Feb 3 2022
Feb 3 2022
Dec 20 2021
Dec 20 2021
Dec 18 2021
Dec 18 2021
I'm less optimistic about the ifp seeing the change required in all drivers, @gallatin odes anyone have any idea on the impact of the ifp pointer chase and fetch versus grabbing it from the already fetched scctx in these hot paths? How would we sync scctx_capenable with ifnet, that seems to be a critical missing implementation from the outset.
Dec 14 2021
Dec 14 2021
In D31485#754650, @erj wrote:Though, part of the problem with this patch is that I'm not entirely sure with what I want the parameters of ift_txq_select to be.
Right now it takes the mbuf pointer which is enough for what we want to do with it in an upcoming ice(4) patch, but in the future I'll need to use DSCP/IP ToS information in that function as well. I think I should be able to put that information inside the mbuf along with something like an M_DSCP flag. Though, one version I had before also had the if_pkt_info_t struct as well as having the headers (partially) parsed before this queue selection function was called in order to avoid having to modify mbufs like that.
Dec 10 2021
Dec 10 2021
Dec 1 2021
Dec 1 2021
Nov 1 2021
Nov 1 2021
Oct 27 2021
Oct 27 2021
In D32585#737015, @np wrote:Note. This change requires PCBGROUP to be retired.
Have you circulated this proposal in the wider -net and -vendor community? I know of one downstream that uses this feature.
Oct 22 2021
Oct 22 2021
kbowling retitled D32603: ixgbe: Update mc filter before FCTRL flags from ixgbe: Update mc filter before FCTL flags to ixgbe: Update mc filter before FCTRL flags.
kbowling retitled D32603: ixgbe: Update mc filter before FCTRL flags from ixgbe: Update mc filter before RCTL flags to ixgbe: Update mc filter before FCTL flags.
Oct 20 2021
Oct 20 2021
Oct 10 2021
Oct 10 2021
It was pointed out to me there is still an issue in that we pick up a new sx within the epoch, both in create and timeout with my patch as is For some reason the epoch _preempt variety doesn't produce a diagnostic so I will look into that code.
Oct 9 2021
Oct 9 2021
Thanks @markj what do you think of this approach using epoch?
In D32388#730851, @jlduran_gmail.com wrote:
Jose submitted a variant where the driver (e1000 in this case) calls the iflib_led_create() function in its post attach. I am open to either approach if anyone has any thoughts one way or the other.
Oct 7 2021
Oct 7 2021
Ping. Awaiting approval
Oct 6 2021
Oct 6 2021
@gallatin can you have another look? The locking model on the e1000 is tricky due to the HW so I stashed the info on attach. There's a separate KASSERT fix for em_print_nvm_info for review as well.