On Mon, Feb 1, 2016 at 3:50 AM, John Fastabend <john.fastab...@gmail.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.
