On 24/05/2019 18:44, Jakub Kicinski wrote:
> On Fri, 24 May 2019 18:27:39 +0100, Edward Cree wrote:
>> On 24/05/2019 18:03, Jakub Kicinski wrote:
>>> Simplest would be to keep a list of offloaders per action, but maybe
>>> something more clever would appear as one rummages through the code.
>> Pr
On 2019-05-24 11:09 a.m., Edward Cree wrote:
Oh, a push rather than pull model?
Right. I thought the switchdev (or what used to be called switchdev)
did a push of some of the tables periodically.
That could work, but I worry about the overhead in the case of very large
numbers of rules (the
On Fri, 24 May 2019 18:27:39 +0100, Edward Cree wrote:
> On 24/05/2019 18:03, Jakub Kicinski wrote:
> > On Fri, 24 May 2019 14:57:24 +0100, Edward Cree wrote:
> >> Argh, there's a problem: an action doesn't have a (directly) associated
> >> block, and all the TC offload machinery nowadays is bui
On 24/05/2019 18:03, Jakub Kicinski wrote:
> On Fri, 24 May 2019 14:57:24 +0100, Edward Cree wrote:
>> Argh, there's a problem: an action doesn't have a (directly) associated
>> block, and all the TC offload machinery nowadays is built around blocks.
>> Since this action might have been used in _a
On Fri, 24 May 2019 14:57:24 +0100, Edward Cree wrote:
> On 24/05/2019 14:09, Edward Cree wrote:
> > I'll put together an RFC patch, anyway
> Argh, there's a problem: an action doesn't have a (directly) associated
> block, and all the TC offload machinery nowadays is built around blocks.
> Since
On 24/05/2019 15:44, Jamal Hadi Salim wrote:
> On 2019-05-24 9:57 a.m., Edward Cree wrote:
>> Argh, there's a problem: an action doesn't have a (directly) associated
>> block, and all the TC offload machinery nowadays is built around blocks.
>> Since this action might have been used in _any_ block
On 2019-05-24 9:57 a.m., Edward Cree wrote:
On 24/05/2019 14:09, Edward Cree wrote:
I'll put together an RFC patch, anyway
Argh, there's a problem: an action doesn't have a (directly) associated
block, and all the TC offload machinery nowadays is built around blocks.
Since this action might h
On 24/05/2019 14:09, Edward Cree wrote:
> I'll put together an RFC patch, anyway
Argh, there's a problem: an action doesn't have a (directly) associated
block, and all the TC offload machinery nowadays is built around blocks.
Since this action might have been used in _any_ block (and afaik there's
On 23/05/2019 18:25, Jakub Kicinski wrote:
> Whether it's on you to fix this is debatable :) Since you're diving
> into actions and adding support for shared ones, I'd say it's time to
> rectify the situation.
>
> Let's look at it this way - if you fix the RTM_GETACTION you will
> necessarily add t
On Thu, 23 May 2019 17:40:08 +0100, Edward Cree wrote:
> On 23/05/2019 17:11, Jakub Kicinski wrote:
> > On Thu, 23 May 2019 09:19:49 -0400, Jamal Hadi Salim wrote:
> >> That would still work here, no? There will be some latency
> >> based on the frequency of hardware->kernel stats updates.
> >
On 23/05/2019 17:33, Jakub Kicinski wrote:
> On Thu, 23 May 2019 17:21:49 +0100, Edward Cree wrote:
>> Well, patch #2 updates drivers to the changed API, which is kinda an
>> "upstream user" if you squint... admittedly patch #1 is a bit dubious
>> in that regard;
> Both 1 and 2 are dubious if you
On 23/05/2019 17:11, Jakub Kicinski wrote:
> On Thu, 23 May 2019 09:19:49 -0400, Jamal Hadi Salim wrote:
>> That would still work here, no? There will be some latency
>> based on the frequency of hardware->kernel stats updates.
> I don't think so, I think the stats are only updated on classifier
>
On Thu, 23 May 2019 17:21:49 +0100, Edward Cree wrote:
> On 22/05/2019 23:20, Jakub Kicinski wrote:
> > On Wed, 22 May 2019 22:37:16 +0100, Edward Cree wrote:
> >> * removed RFC tags
> > Why? There is still no upstream user for this
> Well, patch #2 updates drivers to the changed API, which
On 22/05/2019 23:20, Jakub Kicinski wrote:
> On Wed, 22 May 2019 22:37:16 +0100, Edward Cree wrote:
>> * removed RFC tags
> Why? There is still no upstream user for this
Well, patch #2 updates drivers to the changed API, which is kinda an
"upstream user" if you squint... admittedly patch #1 is a
On Thu, 23 May 2019 09:19:49 -0400, Jamal Hadi Salim wrote:
> On 2019-05-22 6:20 p.m., Jakub Kicinski wrote:
> > On Wed, 22 May 2019 22:37:16 +0100, Edward Cree wrote:
> >> * removed RFC tags
> >
> > Why? There is still no upstream user for this (my previous
> > objections of this being only
On 2019-05-22 6:20 p.m., Jakub Kicinski wrote:
On Wed, 22 May 2019 22:37:16 +0100, Edward Cree wrote:
* removed RFC tags
Why? There is still no upstream user for this (my previous
objections of this being only partially correct aside).
IIRC your point was to get the dumping to work with RT
On Wed, 22 May 2019 22:37:16 +0100, Edward Cree wrote:
> * removed RFC tags
Why? There is still no upstream user for this (my previous
objections of this being only partially correct aside).
When the flow_offload infrastructure was added, per-action statistics,
which were previously possible for drivers to support in TC offload,
were not plumbed through, perhaps because the drivers in the tree did
not implement them.
In TC (and in the previous offload API) statistics are per-action,
18 matches
Mail list logo
