In D22523#495057, @jacob.e.keller_intel.com wrote:

Hmm. I think I understand the change.. but it seems less intuitive.
Do you have any example of how much this improves? I.e. a C program with a large enough test case to show measurable improvement?

Builds okay now.

Don't remove the extra whitespace in if.c

Update patch to make it build on HEAD

I get a build error with this revision:

Adding @jpaetzel since he seemed to be the last person making updates to oce(4); is this change ok to make there? There's no functional change.

@jacob.e.keller_intel.com, is this ready to be committed?

Update review with a first cut version of the code that checks the bus
ranges of upstream pci bridges; this doesn't incorporate suggestions
that jhb@ had made.

• Add a specific iflib flag for VLAN anti-spoof and use it

Resolve merge conflict

Here's the output I got from the first pcib above ice4/ice5 in devinfo:

I like the changes for the Intel ethernet drivers. I've always been uncomfortable with how we were required to manually iterate through the list in the driver using the LIST_FOREACH macros; like you say in your description, if the data structure changes, then it causes a lot of driver thrash.

In D21944#479344, @jhb wrote:

How did this work? Meaning how did you allocate bus numbers? Did the parent PCI-PCI bridge have enough bus numbers in range already? For this to work properly you'd need to ensure that the parent PCI-PCI bridge at the other end of the link has the requested bus numbers mapped into its range of valid bus numbers.

@krzysztof.galazka_intel.com did this get tested yet?

In D21712#474097, @gallatin wrote:

Would it make sense then to assert that the link is down?

Relevant bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240610

Bugzilla link: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240610

Is there a reason that we wouldn't do this for all of our drivers, instead of hardcoding the BAR index?