netdev - Re: [RFC PATCH 3/7] net: sched: add cls

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]

Date:	Tue, 2 Feb 2016 18:25:49 +0200
From:	Or Gerlitz <gerlitz.or@...il.com>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	Anjali Singhai Jain <anjali.singhai@...el.com>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	Jamal Hadi Salim <jhs@...atatu.com>, ast@...com,
	"Skidmore, Donald C" <donald.c.skidmore@...el.com>,
	horms@...ge.net.au, Linux Netdev List <netdev@...r.kernel.org>,
	Thomas Graf <tgraf@...g.ch>,
	David Miller <davem@...emloft.net>,
	Jiri Pirko <jiri@...lanox.com>
Subject: Re: [RFC PATCH 3/7] net: sched: add cls_u32 offload hooks for netdevs

On Mon, Feb 1, 2016 at 3:50 AM, John Fastabend <john.fastabend@...il.com> wrote:
> This patch allows netdev drivers to consume cls_u32 offloads via
> the ndo_setup_tc ndo op.
>
> This works aligns with how network drivers have been doing qdisc
> offloads for mqprio.

[...]

> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -779,17 +779,21 @@ static inline bool netdev_phys_item_id_same(struct netdev_phys_item_id *a,
>  typedef u16 (*select_queue_fallback_t)(struct net_device *dev,
>                                        struct sk_buff *skb);
>
> -/* This structure holds attributes of qdisc and classifiers
> +/* These structures hold the attributes of qdisc and classifiers
>   * that are being passed to the netdevice through the setup_tc op.
>   */
>  enum {
>         TC_SETUP_MQPRIO,
> +       TC_SETUP_CLSU32,
>  };
>
> +struct tc_cls_u32_offload;
> +
>  struct tc_to_netdev {
>         unsigned int type;
>         union {
>                 u8 tc;
> +               struct tc_cls_u32_offload *cls_u32;
>         };
>  };

So under this approach we're making the HW driver u32 aware. Do we
really want to go there?

The flow-dissector + actions structure way of describing matching and
actions maybe had some
drawbacks but it's not affiliated with a specific networking component
(here TC/U32). When we look
fwd do we expect everything (netfilter offloads for example) to be
expressed in u32 terms?

Or.