On 16-02-18 10:24 AM, John Fastabend wrote:
On 16-02-18 04:14 AM, Jamal Hadi Salim wrote:
On 16-02-17 06:07 PM, John Fastabend wrote:
[...]
IMO, it would be better at this early stage to enforce the correct
behavior for future generations.
To follow the netlink semantics which a lot of pe
On Thu, Feb 18, 2016 at 11:23 AM, Amir Vadai" wrote:
> On Wed, Feb 17, 2016 at 03:07:23PM -0800, John Fastabend wrote:
>> Actually thinking about this a bit more I wrote this thinking
>> that there existed some hardware that actually cared if it was
>> a new rule or an existing rule. For me it do
On Thu, Feb 18, 2016 at 11:23:35AM +0200, Amir Vadai" wrote:
> On Wed, Feb 17, 2016 at 03:07:23PM -0800, John Fastabend wrote:
> > [...]
> >
> > >>
> > >>> +static void u32_replace_hw_hnode(struct tcf_proto *tp, struct
> > >>> tc_u_hnode *h)
> > >>> +{
> > >>> +struct net_device *dev = tp->q->
On 16-02-18 04:14 AM, Jamal Hadi Salim wrote:
> On 16-02-17 06:07 PM, John Fastabend wrote:
>> [...]
>>
>
>> Actually thinking about this a bit more I wrote this thinking
>> that there existed some hardware that actually cared if it was
>> a new rule or an existing rule. For me it doesn't matter I
On 16-02-17 06:07 PM, John Fastabend wrote:
[...]
Actually thinking about this a bit more I wrote this thinking
that there existed some hardware that actually cared if it was
a new rule or an existing rule. For me it doesn't matter I do
the same thing in the new/replace cases I just write int
On Wed, Feb 17, 2016 at 03:07:23PM -0800, John Fastabend wrote:
> [...]
>
> >>
> >>> +static void u32_replace_hw_hnode(struct tcf_proto *tp, struct
> >>> tc_u_hnode *h)
> >>> +{
> >>> +struct net_device *dev = tp->q->dev_queue->dev;
> >>> +struct tc_cls_u32_offload u32_offload = {0};
> >>>
[...]
>>
>>> +static void u32_replace_hw_hnode(struct tcf_proto *tp, struct
>>> tc_u_hnode *h)
>>> +{
>>> +struct net_device *dev = tp->q->dev_queue->dev;
>>> +struct tc_cls_u32_offload u32_offload = {0};
>>> +struct tc_to_netdev offload;
>>> +
>>> +offload.type = TC_SETUP_CLSU32;
On 16-02-17 02:59 AM, Jamal Hadi Salim wrote:
> On 16-02-17 12:17 AM, John Fastabend 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.
>>
>
> This one
On 16-02-17 12:17 AM, John Fastabend 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.
This one i have comments on.
Signed-off-by: John Fastabend
---
inclu
Wed, Feb 17, 2016 at 06:17:09AM CET, 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.
>
>Signed-off-by: John Fastabend
Acked-by: Jir
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.
Signed-off-by: John Fastabend
---
include/linux/netdevice.h |6 ++-
include/net/pkt_cls.h | 34 ++
11 matches
Mail list logo