netdev - Re: [net-next PATCH 02/15] net: Merge VXLAN and GENEVE push notifiers into a single notifier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKgT0UcbqAvN=NprtD8hsK-y1ex5m8wPOZinTVPHi72yoqwVsw@mail.gmail.com>
Date:	Mon, 13 Jun 2016 14:58:35 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Hannes Frederic Sowa <hannes@...hat.com>
Cc:	Alexander Duyck <aduyck@...antis.com>,
	Netdev <netdev@...r.kernel.org>,
	intel-wired-lan <intel-wired-lan@...ts.osuosl.org>,
	Jesse Gross <jesse@...nel.org>, Jiri Benc <jbenc@...hat.com>,
	Saeed Mahameed <saeedm@...lanox.com>,
	Ariel Elior <ariel.elior@...gic.com>,
	Tom Herbert <tom@...bertland.com>,
	Dept-GELinuxNICDev@...gic.com, David Miller <davem@...emloft.net>,
	Eugenia Emantayev <eugenia@...lanox.com>
Subject: Re: [net-next PATCH 02/15] net: Merge VXLAN and GENEVE push notifiers
 into a single notifier

On Mon, Jun 13, 2016 at 2:08 PM, Hannes Frederic Sowa <hannes@...hat.com> wrote:
> On 13.06.2016 21:47, Alexander Duyck wrote:
>> On Mon, Jun 13, 2016 at 10:57 AM, Hannes Frederic Sowa
>> <hannes@...hat.com> wrote:
>>> Hi Alex,
>>>
>>> very cool series!
>>>
>>> On 13.06.2016 19:48, Alexander Duyck wrote:
>>>> 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