netdev - Re: [PATCH v3 2/4] i40e: geneve tunnel offload support

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: <CAEh+42jr+8Q65Zp0A+NE3jZSBe5nvnbaT6Zpx_JUHG0=MOUVhw@mail.gmail.com>
Date:	Tue, 8 Dec 2015 10:36:03 -0800
From:	Jesse Gross <jesse@...nel.org>
To:	Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:	Anjali Singhai Jain <anjali.singhai@...el.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	jeffrey.t.kirsher@...el.org, Kiran Patil <kiran.patil@...el.com>,
	Tom Herbert <tom@...bertland.com>
Subject: Re: [PATCH v3 2/4] i40e: geneve tunnel offload support

On Tue, Dec 8, 2015 at 10:20 AM, Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
> On Tue, Dec 08, 2015 at 10:12:12AM -0800, Anjali Singhai Jain wrote:
>> +/**
>> + * i40e_add_geneve_port - Get notifications about GENEVE ports that come up
>> + * @netdev: This physical port's netdev
>> + * @sa_family: Socket Family that GENEVE is notifying us about
>> + * @port: New UDP port number that GENEVE started listening to
>> + **/
>> +static void i40e_add_geneve_port(struct net_device *netdev,
>> +                              sa_family_t sa_family, __be16 port)
>> +{
>> +#if IS_ENABLED(CONFIG_GENEVE)
> ...
>> +     /* New port: add it and mark its index in the bitmap */
>> +     pf->udp_ports[next_idx].index = port;
>> +     pf->udp_ports[next_idx].type = I40E_AQC_TUNNEL_TYPE_NGE;
>
> the function suppose to deal with geneve but tunnel type is NGE ?!

NGE is an old name for Geneve: "Next Generation Encapsulation"

>> -#define I40E_MAX_TUNNEL_HDR_LEN 80
>> +/* Hardware supports L4 tunnel length of 128B (=2^7) which includes
>> + * inner mac plus all inner ethertypes.
>> + */
>> +#define I40E_MAX_TUNNEL_HDR_LEN 128
>
> so the driver lied about actual hw capabilities earlier
> or it needs firmware update to work this way?

I'm pretty sure that this is just making the calculation match the
hardware more accurately. If you look at the code below it, it is now
calculating the length from a different place.

>> -     if (!(tx_flags & I40E_TX_FLAGS_VXLAN_TUNNEL)) {
>> +     if (!(tx_flags & I40E_TX_FLAGS_UDP_TUNNEL)) {
> ...
>> @@ -163,7 +163,7 @@ enum i40e_dyn_idx_t {
>>  #define I40E_TX_FLAGS_FSO            BIT(7)
>>  #define I40E_TX_FLAGS_TSYN           BIT(8)
>>  #define I40E_TX_FLAGS_FD_SB          BIT(9)
>> -#define I40E_TX_FLAGS_VXLAN_TUNNEL   BIT(10)
>> +#define I40E_TX_FLAGS_UDP_TUNNEL     BIT(10)
>
> these changes implying that HW actually doesn't have special 'geneve or vxlan'
> hard coded logic and it's generic enough to understand most of udp tunnels.
> Then why you cannot generalize this whole things as generic udp tunnel offload
> and do not add any protocol specific hooks and ndos.

These are transmit flags but the issue of specialization relates to receive.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html