Thread (17 messages) flat view 17 messages, 4 authors, 2016-02-02

Re: [RFC PATCH 3/7] net: sched: add cls_u32 offload hooks for netdevs

From: Or Gerlitz <hidden>
Date: 2016-02-02 16:25:50

On Mon, Feb 1, 2016 at 3:50 AM, John Fastabend [off-list ref] 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.
[...]
quoted hunk ↗ jump to hunk
--- 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help