Re: [net-next PATCH 02/15] net: Merge VXLAN and GENEVE push notifiers into a single notifier
From: Alexander Duyck <hidden>
Date: 2016-06-13 21:58:37
Also in:
intel-wired-lan
On Mon, Jun 13, 2016 at 2:08 PM, Hannes Frederic Sowa [off-list ref] wrote:
On 13.06.2016 21:47, Alexander Duyck wrote:quoted
On Mon, Jun 13, 2016 at 10:57 AM, Hannes Frederic Sowa [off-list ref] wrote:quoted
Hi Alex, very cool series! On 13.06.2016 19:48, Alexander Duyck wrote:quoted
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index d101e4d904ba..e959b6348f91 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h@@ -1269,6 +1269,14 @@ struct net_device_ops { void (*ndo_del_geneve_port)(struct net_device *dev, sa_family_t sa_family, __be16 port); + void (*ndo_add_udp_enc_port)(struct net_device *dev, + sa_family_t sa_family, + __be16 port, + unsigned int type); + void (*ndo_del_udp_enc_port)(struct net_device *dev, + sa_family_t sa_family, + __be16 port, + unsigned int type); void* (*ndo_dfwd_add_station)(struct net_device *pdev, struct net_device *dev); void (*ndo_dfwd_del_station)(struct net_device *pdev,What do you think about adding a struct as argument to ndo_*_udp_enc_port? As a result we can much easier add new fields in case future NICs allow us to e.g. specify a bound ip address?Actually that is probably a good idea. Suggestions on the name are welcome. Otherwise I will try to come up with something in a bit as I am currently going through and flushing out all the driver specific VXLAN and GENEVE build flags.Hmmm... struct net_device_hw_offload, to be most generic? Maybe we can even drop the udp_enc in the name and go completely generic: int (*ndo_apply_offload)(..., struct hw_offload).
The only probably with generically using the offload keyword is it is not very clear about what is going on. For now I am just going with udp_enc_endpoint_info since that is basically what we are passing. Then I just use the pointer variable ei for passing it back and forth between the functions.
(enc reminded me too much at encryption)
I don't know. In a way that isn't too far off since we are looking at packet data buried inside of a UDP packet. I thought it worked based on the fact that we have hw_enc_features which is what is used to indicate the hw features when a packet is encapsulated. I could add a few more letters and move things over to "encap" if you prefer. It just means adding 2 more letters.
Another idea, should we add error indications also for the future? We can signal if a specific card was not able to enable offloading. Different situations can be signaled: port list depleted, protocol unsupported etc. Might make sense for later postprocessing and signaling to user space.
The problem is we are using a notifier type setup. As such we cannot really exit out if an error occurs on one of the ports. - Alex