I'm recently fighting with ifp->if_drv_flags & IFF_DRV_RUNNING. I think the flag should ( if ever wanted ) be write only by the driver and protected by driver locks, but not by the net stack. For sync issue, the net stack should use atomic_load but not merely a test by ifp->if_drv_flags & IFF_DRV_RUNNING.

IMHO, the idea of the flag was not correct in the first place. A new properly written driver shall not rely on it as a measure to prevent the stack from talking to the driver.

D54443: @zlei
This is an example of netlink implementation of ifconfig for geneve.
For the same reason, we need the nl_parsed_geneve here.
That's why I want the nl_parsed_gre to be public KPI.

I'd like to test this HW offload feature for GENEVE, but I think the ethernet drivers in-tree are not ready for that yet. @pouria Do you have any WIP updates for any drivers ?

The sx lock geneve_sx is only used in this file. Make it static to limit the scope.

I guess a memcmp() is sufficient ?

The in-tree drivers are approaching to netlink based config. Shall we still support nvlist ?
@kp How do you think about this ?

No need for parentheses in case labels.

Ditto.

I believe the default branch is unreachable.

Shall the drivers be updated to support the inner csum offload ?

Unreachable code.

The ip_output() shall handle the mbuf, and free it if error occurs. So this is not required.

Ditto.

Shall this move to VNET_SYSUNINIT ?

You're right. There are drivers that should support GENEVE hw offload, but not implemented yet.
I want to work on it after geneve lands.
I'm currently busy with v6 and routing stack.

It'll be used in line 785 to order entries on the ftable.
It's basically the same mechanism used in if_vxlan.

np from me. I've a branch prepared without nvlist.
I also like to remove the nvlist support too.

In that case, IMHO, we shouldn't panic.

Of course, but I don't want to update them on this revision.
I prepared the CSUM requirements for geneve here and I'll update other drivers in another revision.

It should, but please see the D54175.

kind ping @kp

I'm entirely on board with the "Netlink only" approach. I don't think it's a good idea to have multiple different sets of configuration code. Just do netlink, it's the best available option right now.

IMO the cloner is not to be blamed.

( The socket ) Leaking of refcount of prison should be handled properly on prison remove event. I have an idea to fix it, then destroy cloner via VNET_SYSUNINIT should work as intended.

why are there semicolons here? :p

bad habit of declaring first and copying from it.
Nice catch!
How did you find that? :)))