netdev - Re: [PATCH 1/3] netdev: introduce new NETIF_F_HW_SWITCH_OFFLOAD feature flag for switch device offloads

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: <54815180.30900@gmail.com>
Date:	Thu, 04 Dec 2014 22:32:32 -0800
From:	John Fastabend <john.fastabend@...il.com>
To:	Scott Feldman <sfeldma@...il.com>
CC:	Roopa Prabhu <roopa@...ulusnetworks.com>,
	Jiří Pírko <jiri@...nulli.us>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	Benjamin LaHaise <bcrl@...ck.org>, Thomas Graf <tgraf@...g.ch>,
	"stephen@...workplumber.org" <stephen@...workplumber.org>,
	John Linville <linville@...driver.com>,
	"nhorman@...driver.com" <nhorman@...driver.com>,
	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	"vyasevic@...hat.com" <vyasevic@...hat.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	"buytenh@...tstofly.org" <buytenh@...tstofly.org>,
	Aviad Raveh <aviadr@...lanox.com>,
	Netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>, shm@...ulusnetworks.com,
	Andy Gospodarek <gospo@...ulusnetworks.com>
Subject: Re: [PATCH 1/3] netdev: introduce new NETIF_F_HW_SWITCH_OFFLOAD feature
 flag for switch device offloads

On 12/04/2014 10:08 PM, Scott Feldman wrote:
> On Thu, Dec 4, 2014 at 6:26 PM,  <roopa@...ulusnetworks.com> wrote:
>> From: Roopa Prabhu <roopa@...ulusnetworks.com>
>>
>> This is a generic high level feature flag for all switch asic features today.
>>
>> switch drivers set this flag on switch ports. Logical devices like
>> bridge, bonds, vxlans can inherit this flag from their slaves/ports.
>>
>> I had to use SWITCH in the name to avoid ambiguity with other feature
>> flags. But, since i have been harping about not calling it 'switch',
>> I am welcome to any suggestions :)
>>
>> An alternative to using a feature flag is to use a IFF_HW_OFFLOAD
>> in net_device_flags.
>> ---
>>   include/linux/netdev_features.h |    2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
>> index 8e30685..68db1de 100644
>> --- a/include/linux/netdev_features.h
>> +++ b/include/linux/netdev_features.h
>> @@ -66,6 +66,7 @@ enum {
>>          NETIF_F_HW_VLAN_STAG_FILTER_BIT,/* Receive filtering on VLAN STAGs */
>>          NETIF_F_HW_L2FW_DOFFLOAD_BIT,   /* Allow L2 Forwarding in Hardware */
>>          NETIF_F_BUSY_POLL_BIT,          /* Busy poll */
>> +       NETIF_F_HW_SWITCH_OFFLOAD_BIT,  /* HW switch offload */
>>
>>          /*
>>           * Add your fresh new feature above and remember to update
>> @@ -124,6 +125,7 @@ enum {
>>   #define NETIF_F_HW_VLAN_STAG_TX        __NETIF_F(HW_VLAN_STAG_TX)
>>   #define NETIF_F_HW_L2FW_DOFFLOAD       __NETIF_F(HW_L2FW_DOFFLOAD)
>>   #define NETIF_F_BUSY_POLL      __NETIF_F(BUSY_POLL)
>> +#define NETIF_F_HW_SWITCH_OFFLOAD      __NETIF_F(HW_SWITCH_OFFLOAD)
>
> Can we use existing flag NETIF_F_HW_L2FW_DOFFLOAD?  The comment above
> on that flag suggests it would be perfect for what we're doing with L2
> bridging: offloading the L2 forwarding path in HW.
>
> NETIF_F_HW_L2FW_DOFFLOAD seems to be orphaned in current net-next, so
> I'm not sure of it's status, but see if it makes sense to recycle it.
>
> I could see a NETIF_F_HW_L3FW_DOFFLOAD for L3 fwd offload, down the road.
>

Its not orphaned its used by the macvlan device to indicate that the
port switching should be done in hardware. For example put macvlan in
VEPA mode and the hardware will deliver the packets directly to the
netdev and get the pruning right. In VEB mode the hardware will forward
packets correctly between macvlan netdevs. The implementation on ixgbe
for example is to give a set of hardware queues per macvlan netdev. I
still need to add offloaded QOS to make this more interesting.

I could support a l3vlan device as well even on some of the host nics.

The issue with generalizing it is at the moment it is used by ixgbe
which can't forward between two physical ports. It works on macvlan
because each macvlan netdev uses the same physical uplink. I think 
switching between different ports is going to require another feature
bit like its done here.

.John

>
>>   /* Features valid for ethtool to change */
>>   /* = all defined minus driver/device-class-related */
>> --
>> 1.7.10.4
>>


-- 
John Fastabend         Intel Corporation
--
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