Wed, Nov 02, 2016 at 04:22:50PM CET, john.fastab...@gmail.com wrote:
[...]
>>>
>>> What is your compilerA? Is that part of tc in user space? Maybe linked
>>
>> It is something that transforms original p4 source to some intermediate
>> form, easy to be processed by in-kernel compilers.
>>
>>
>>
[...]
> Exactly. Following drawing shows p4 pipeline setup for SW and Hw:
>
> |
> | +--> ebpf engine
> | |
> |
Wed, Nov 02, 2016 at 04:18:06PM CET, john.fastab...@gmail.com wrote:
>On 16-11-02 01:07 AM, Jiri Pirko wrote:
>> Tue, Nov 01, 2016 at 04:13:32PM CET, john.fastab...@gmail.com wrote:
[...]
>[...]>
>>>
>>> Same question as above are we _really_ talking about pushing the entire
>>> programmability
On 16-11-02 01:07 AM, Jiri Pirko wrote:
> Tue, Nov 01, 2016 at 04:13:32PM CET, john.fastab...@gmail.com wrote:
>> [...]
>>
> P4 is ment to program programable hw, not fixed pipeline.
>
I'm guessing there are no upstream drivers at the moment that support
this though right? Th
> > > > > > On Sat, 29 Oct 2016 09:53:28 +0200, Jiri Pirko wrote:
>> > > > > > > > Hi all.
>> >
>> > sorry for delay. travelling to KS, so probably missed something in
>> > this thread and comments can be totally off...
>>
Tue, Nov 01, 2016 at 04:13:32PM CET, john.fastab...@gmail.com wrote:
>[...]
>
P4 is ment to program programable hw, not fixed pipeline.
>>>
>>> I'm guessing there are no upstream drivers at the moment that support
>>> this though right? The rocker universe bits though could leverage this.
> Sorry for jumping into the middle and the delay (plumbers this week). My
> question would be, if the main target is for p4 *offloading* anyway, who
> would use this sw fallback path? Mostly for testing purposes?
>
> I'm not sure about compilerB here and the complexity that needs to be
> pushed in
at 06:46:21PM CEST, john.fastab...@gmail.com wrote:
On 16-10-29 07:49 AM, Jakub Kicinski wrote:
On Sat, 29 Oct 2016 09:53:28 +0200, Jiri Pirko wrote:
Hi all.
sorry for delay. travelling to KS, so probably missed something in
this thread and comments can be totally off...
the subject "let
[...]
>>> P4 is ment to program programable hw, not fixed pipeline.
>>>
>>
>> I'm guessing there are no upstream drivers at the moment that support
>> this though right? The rocker universe bits though could leverage this.
>
> mlxsw. But this is naturaly not implemented yet, as there is no
> infr
On 16-11-01 04:57 AM, Jamal Hadi Salim wrote:
>
> I am in travel mode so havent read the huge blast of
> emails (and i am probably taking this email out of
> the already discussed topics). I will try to catchup later.
>
> Simple question (same chat I had with Prem at netdev1.2):
> What is it that
I am in travel mode so havent read the huge blast of
emails (and i am probably taking this email out of
the already discussed topics). I will try to catchup later.
Simple question (same chat I had with Prem at netdev1.2):
What is it that can be expressed by P4 that cant be expressed
with the (us
Mon, Oct 31, 2016 at 08:35:00PM CET, john.fastab...@gmail.com wrote:
>[...]
>
>>>
>>> I think the issue with offloading a P4-AST will be how much work goes
>>> into mapping this onto any particular hardware instance. And how much
>>> of the P4 language feature set is exposed.
>>>
>>> For examp
[...]
>>>
>>
>> I think the issue with offloading a P4-AST will be how much work goes
>> into mapping this onto any particular hardware instance. And how much
>> of the P4 language feature set is exposed.
>>
>> For example I suspect MLX switch has a different pipeline than MLX NIC
>> and even diff
On 31.10.2016 18:12, Jiri Pirko wrote:
>> >
>> >In the naive implementation only pipelines that map 1:1 will work. Maybe
>> >this is what Alexei is noticing?
> P4 is ment to program programable hw, not fixed pipeline.
Is it realistic to assume that future hardware might be programmed with
a propri
>> On Sat, 29 Oct 2016 09:53:28 +0200, Jiri Pirko wrote:
>>>>>>>>> Hi all.
>>>>>>>>>
>>>
>>> sorry for delay. travelling to KS, so probably missed something in
>>> this thread and comments can be totally off...
Hi all.
>>>>>>>>
>>
>> sorry for delay. travelling to KS, so probably missed something in
>> this thread and comments can be totally off...
>>
>> the subject "let's do P4" is imo misleading, since it reads like
>> we don't
ng to KS, so probably missed something in
>this thread and comments can be totally off...
>
>the subject "let's do P4" is imo misleading, since it reads like
>we don't do P4 at the moment, whereas the opposite is true.
>Several p4->bpf compilers is a proof.
Mon, Oct 31, 2016 at 07:03:53AM CET, zenczykow...@gmail.com wrote:
>One thing to consider...
>
>Just because the compiler could be in the kernel, doesn't mean it has to be.
>
>One could envision a hotplug/modprobe like helper program that the
>kernel executes
>when it wants to translate from one en
One thing to consider...
Just because the compiler could be in the kernel, doesn't mean it has to be.
One could envision a hotplug/modprobe like helper program that the
kernel executes
when it wants to translate from one encoding (say p4) to another (say [e]bpf).
This keeps complexity (compiler)
07:49 AM, Jakub Kicinski wrote:
> >> >> On Sat, 29 Oct 2016 09:53:28 +0200, Jiri Pirko wrote:
> >> >>> Hi all.
> >> >>>
sorry for delay. travelling to KS, so probably missed something in
this thread and comments can be totally off...
the subject "let
On 16-10-30 12:56 PM, Jiri Pirko wrote:
> Sun, Oct 30, 2016 at 07:44:43PM CET, kubak...@wp.pl wrote:
>> On Sun, 30 Oct 2016 19:01:03 +0100, Jiri Pirko wrote:
>>> Sun, Oct 30, 2016 at 06:45:26PM CET, kubak...@wp.pl wrote:
On Sun, 30 Oct 2016 17:38:36 +0100, Jiri Pirko wrote:
> Sun, Oct 30
[...]
>
> Yeah, I was also thinking about something similar to your Flow-API,
> but we need something more generic I believe.
I've heard this in a couple other forums as well but please elaborate
exactly what needs to be more generic? That API is sufficient to both
express the init time piece of
Sun, Oct 30, 2016 at 07:44:43PM CET, kubak...@wp.pl wrote:
>On Sun, 30 Oct 2016 19:01:03 +0100, Jiri Pirko wrote:
>> Sun, Oct 30, 2016 at 06:45:26PM CET, kubak...@wp.pl wrote:
>> >On Sun, 30 Oct 2016 17:38:36 +0100, Jiri Pirko wrote:
>> >> Sun, Oct 30, 2016 at 11:26:49AM CET, tg...@suug.ch wrote:
On Sun, 30 Oct 2016 19:01:03 +0100, Jiri Pirko wrote:
> Sun, Oct 30, 2016 at 06:45:26PM CET, kubak...@wp.pl wrote:
> >On Sun, 30 Oct 2016 17:38:36 +0100, Jiri Pirko wrote:
> >> Sun, Oct 30, 2016 at 11:26:49AM CET, tg...@suug.ch wrote:
> [...]
> [...]
> >> [...]
> >> [...]
> >> [...
Sun, Oct 30, 2016 at 06:45:26PM CET, kubak...@wp.pl wrote:
>On Sun, 30 Oct 2016 17:38:36 +0100, Jiri Pirko wrote:
>> Sun, Oct 30, 2016 at 11:26:49AM CET, tg...@suug.ch wrote:
>> >On 10/30/16 at 08:44am, Jiri Pirko wrote:
>> >> Sat, Oct 29, 2016 at 06:46:21PM CEST, john.fastab...@gmail.com wrote:
On Sun, 30 Oct 2016 17:38:36 +0100, Jiri Pirko wrote:
> Sun, Oct 30, 2016 at 11:26:49AM CET, tg...@suug.ch wrote:
> >On 10/30/16 at 08:44am, Jiri Pirko wrote:
> >> Sat, Oct 29, 2016 at 06:46:21PM CEST, john.fastab...@gmail.com wrote:
> [...]
> [...]
> [...]
> [...]
> >
> >My assumpt
Sun, Oct 30, 2016 at 11:26:49AM CET, tg...@suug.ch wrote:
>On 10/30/16 at 08:44am, Jiri Pirko wrote:
>> Sat, Oct 29, 2016 at 06:46:21PM CEST, john.fastab...@gmail.com wrote:
>> >On 16-10-29 07:49 AM, Jakub Kicinski wrote:
>> >> On Sat, 29 Oct 2016 09:53:28 +0200, Jiri Pirko wrote:
>> >>> Hi all.
>>
On 10/30/16 at 08:44am, Jiri Pirko wrote:
> Sat, Oct 29, 2016 at 06:46:21PM CEST, john.fastab...@gmail.com wrote:
> >On 16-10-29 07:49 AM, Jakub Kicinski wrote:
> >> On Sat, 29 Oct 2016 09:53:28 +0200, Jiri Pirko wrote:
> >>> Hi all.
> >>>
> >>> The network world is divided into 2 general types of
Sat, Oct 29, 2016 at 06:46:21PM CEST, john.fastab...@gmail.com wrote:
>On 16-10-29 07:49 AM, Jakub Kicinski wrote:
>> On Sat, 29 Oct 2016 09:53:28 +0200, Jiri Pirko wrote:
>>> Hi all.
>>>
>>> The network world is divided into 2 general types of hw:
>>> 1) network ASICs - network specific silicon, c
On 16-10-29 07:49 AM, Jakub Kicinski wrote:
> On Sat, 29 Oct 2016 09:53:28 +0200, Jiri Pirko wrote:
>> Hi all.
>>
>> The network world is divided into 2 general types of hw:
>> 1) network ASICs - network specific silicon, containing things like TCAM
>>These ASICs are suitable to be programmed b
Sat, Oct 29, 2016 at 04:54:21PM CEST, kubak...@wp.pl wrote:
>On Sat, 29 Oct 2016 15:58:55 +0200, Jiri Pirko wrote:
>> Sat, Oct 29, 2016 at 02:09:32PM CEST, tg...@suug.ch wrote:
>> >On 10/29/16 at 01:28pm, Jiri Pirko wrote:
>> >> Sat, Oct 29, 2016 at 01:15:48PM CEST, tg...@suug.ch wrote:
>> >> >
Sat, Oct 29, 2016 at 04:49:03PM CEST, kubak...@wp.pl wrote:
>On Sat, 29 Oct 2016 09:53:28 +0200, Jiri Pirko wrote:
>> Hi all.
>>
>> The network world is divided into 2 general types of hw:
>> 1) network ASICs - network specific silicon, containing things like TCAM
>>These ASICs are suitable to
On Sat, 29 Oct 2016 15:58:55 +0200, Jiri Pirko wrote:
> Sat, Oct 29, 2016 at 02:09:32PM CEST, tg...@suug.ch wrote:
> >On 10/29/16 at 01:28pm, Jiri Pirko wrote:
> >> Sat, Oct 29, 2016 at 01:15:48PM CEST, tg...@suug.ch wrote:
> >> >So given the SKIP_SW flag, the in-kernel compiler is optional any
On Sat, 29 Oct 2016 09:53:28 +0200, Jiri Pirko wrote:
> Hi all.
>
> The network world is divided into 2 general types of hw:
> 1) network ASICs - network specific silicon, containing things like TCAM
>These ASICs are suitable to be programmed by P4.
> 2) network processors - basically a genera
Sat, Oct 29, 2016 at 02:09:32PM CEST, tg...@suug.ch wrote:
>On 10/29/16 at 01:28pm, Jiri Pirko wrote:
>> Sat, Oct 29, 2016 at 01:15:48PM CEST, tg...@suug.ch wrote:
>> >So given the SKIP_SW flag, the in-kernel compiler is optional anyway.
>> >Why even risk including a possibly incomplete compiler? O
On 10/29/16 at 01:28pm, Jiri Pirko wrote:
> Sat, Oct 29, 2016 at 01:15:48PM CEST, tg...@suug.ch wrote:
> >So given the SKIP_SW flag, the in-kernel compiler is optional anyway.
> >Why even risk including a possibly incomplete compiler? Older kernels
> >must be capable of running along newer hardware
Sat, Oct 29, 2016 at 01:15:48PM CEST, tg...@suug.ch wrote:
>On 10/29/16 at 12:10pm, Jiri Pirko wrote:
>> Sat, Oct 29, 2016 at 11:39:05AM CEST, tg...@suug.ch wrote:
>> >On 10/29/16 at 09:53am, Jiri Pirko wrote:
>> >> 3) Expose the p4ast in-kernel interpreter to userspace
>> >>As the easiest way
On 10/29/16 at 12:10pm, Jiri Pirko wrote:
> Sat, Oct 29, 2016 at 11:39:05AM CEST, tg...@suug.ch wrote:
> >On 10/29/16 at 09:53am, Jiri Pirko wrote:
> >> 3) Expose the p4ast in-kernel interpreter to userspace
> >>As the easiest way I see in to introduce a new TC classifier cls_p4.
> >>
> >>
Sat, Oct 29, 2016 at 11:39:05AM CEST, tg...@suug.ch wrote:
>On 10/29/16 at 09:53am, Jiri Pirko wrote:
>> Hi all.
>>
>> The network world is divided into 2 general types of hw:
>> 1) network ASICs - network specific silicon, containing things like TCAM
>>These ASICs are suitable to be programme
On 10/29/16 at 09:53am, Jiri Pirko wrote:
> Hi all.
>
> The network world is divided into 2 general types of hw:
> 1) network ASICs - network specific silicon, containing things like TCAM
>These ASICs are suitable to be programmed by P4.
> 2) network processors - basically a general purpose CP
Hi all.
The network world is divided into 2 general types of hw:
1) network ASICs - network specific silicon, containing things like TCAM
These ASICs are suitable to be programmed by P4.
2) network processors - basically a general purpose CPUs
These processors are suitable to be programmed b
41 matches
Mail list logo
