[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ3xEMizet2Cz53dd1LxseO6F=CSO1doFuThJYCQquR7n=cBuQ@mail.gmail.com>
Date: Tue, 16 Feb 2016 22:46:19 +0200
From: Or Gerlitz <gerlitz.or@...il.com>
To: David Miller <davem@...emloft.net>
Cc: john fastabend <john.fastabend@...il.com>,
Amir Vadai <amir@...ai.me>,
Jamal Hadi Salim <jhs@...atatu.com>,
Linux Netdev List <netdev@...r.kernel.org>,
Jiří Pírko <jiri@...nulli.us>,
Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Subject: Re: [net-next PATCH v2 0/8] tc offload for cls_u32 on ixgbe
On Tue, Feb 16, 2016 at 9:50 PM, David Miller <davem@...emloft.net> wrote:
> From: Or Gerlitz <gerlitz.or@...il.com>
> Date: Tue, 16 Feb 2016 21:30:18 +0200
>> I thought we've got into agreement in netdev that the offloading
>> directive would be a tri-state creature (sw, hw and fail the op if
>> can't, hw and fallback to sw). Can you please elaborate what do you
>> mean by "make the offload decision per rule using flags similar to how
>> we do l2 mac updates"
> I think John's changes are an intermediate step in a long term evolution.
sure
> I'm going to apply John's changes as-is, and people can submit relative
> changes on top if they want.
Understood, still I'd be happy to hear what does make the offload
decision per rule using flags similar to how we do l2 mac updates
means. Re the tri-state which you've referred to in netdev -- my
understanding is that we're talking on that flag coming from the user
as part of the tc command line.
Or.
Powered by blists - more mailing lists