We'll hold off on doing anything with this until we're ready to upstream the actual RDMA driver and associated code; there may be some more changes identified.

Rebase on latest main

Rebase on latest main

Rebase on updated parent

Add tunable to allow disabling FW health event reporting by the driver

In D30889#695024, @stallamr_netapp.com wrote:

Yes, I meant in-tree-kernel version. Do you have plan to upstream OOT irdma driver ?

In D30889#694858, @stallamr_netapp.com wrote:

Eric,

I donot see "irdma" available yet in FreeBSD ?

D30691 replaces this revision.

I don't see any glaring problems with it that should block it from going upstream. Are you going to announce this addition on the mailing lists?

I also don't really understand what this is supposed to fix; we haven't had problems registering VLANs at all.

Reading what Sai wrote, I think the best approach from an Intel perspective is to account for Tx data in the AIM calculation; we shouldn't be splitting the Tx/Rx interrupts.

In D30094#676924, @gallatin wrote:

In D30094#676876, @stallamr_netapp.com wrote:

2. In true spirit, if real intention of IFLIB is to split Rx and Tx queues, then we better have unique IRQs for Rx and Tx queues. So, one cannot influence the other. But this again would increase the need/demand for more IRQs on a given node.

It seems like it would be simplest to split tx/rx interrupts and see if the moderation rate on the rx irq was as expected. We recently bumped the max number of msx vectors in an amd64 system, so perhaps whatever decision lead to tying tx/rx together could be revisited.

Were there any other hacks or hardware workarounds? I think they usually add some every generation, but maybe they've finally stopped with these last I219 versions.

I think that for now, since FreeBSD 13.0 has released, we're going to wait on this until we have an implementation of VXLAN offload in ixl(4) that's ready to be upstreamed that will use this.

Committed.

It'd be nice to get this into 13.0 -- that means at least out of tree iflib drivers can be updated to support VXLAN offload on 13.0-RELEASE.

Is this going to get committed soon? Possibly for inclusion in 13.0?

@krzysztof.galazka_intel.com, do you have any update on an answer to @vmaffione's question ?

Did this get tested?

Has anyone else looked at this yet? I haven't had a chance to.

In D21223#479325, @erj wrote:

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

• Commit the ice_ddp package in a separate commit

So, it sounds like it'd be preferred to use (void)0 instead of using an empty stub?

Is this going to get committed?

• Actually make the new ice_vlan_mode.c file that was added

• ice: Update to 0.28.1-k from 0.28.0-k, restore changes made by non-Intel commits

I also need to make other changes to this, too.