On 10/06/14 at 11:47am, Or Gerlitz wrote:
> On Sat, Sep 27, 2014 at 12:02 AM, Thomas Graf wrote:
> > On 09/26/14 at 11:03pm, Or Gerlitz wrote:
> >> Also, this BoF needs to be double-len, two hours, can you act to
> >> get that done?
> >
> > This has already been requested.
>
> Is this confirmed?
On Sat, Sep 27, 2014 at 12:02 AM, Thomas Graf wrote:
> On 09/26/14 at 11:03pm, Or Gerlitz wrote:
>> Yep, this can serve us for the architecture discussion @ LPC. Re the
>> SRIOV case, you referred to the case where guest VF traffic goes
>> through HW (say) VXLAN encap/decap -- just to make sure, w
On 09/26/14 at 11:03pm, Or Gerlitz wrote:
> Yep, this can serve us for the architecture discussion @ LPC. Re the
> SRIOV case, you referred to the case where guest VF traffic goes
> through HW (say) VXLAN encap/decap -- just to make sure, we need also
> to support the simpler case, where guest traf
On Wed, Sep 24, 2014 at 4:32 PM, Thomas Graf wrote:
> On 09/23/14 at 06:32pm, Or Gerlitz wrote:
>> Indeed.
>>
>> The idea is to leverage OVS to manage eSwitch (embedded NIC switch) as well
>> (NOT to offload OVS).
>>
>> We envision a seamless integration of user environment which is based on OVS
>
On 09/23/14 at 06:32pm, Or Gerlitz wrote:
> Indeed.
>
> The idea is to leverage OVS to manage eSwitch (embedded NIC switch) as well
> (NOT to offload OVS).
>
> We envision a seamless integration of user environment which is based on OVS
> with SRIOV eSwitch and the grounds for that were very well
> SKB_GSO_UDP_TUNNEL_CSUM was the right way
> to start splitting overloaded and messy semantics of
> UDP_TUNNEL. I'm still not sure whether you've intended
> it for both rx and tx, since to support tunnel_csum on rx,
> parsing of encap is needed, whereas tx is so much simpler.
> Unless you're assum
On 9/23/2014 7:11 AM, Andy Gospodarek wrote:
On Mon, Sep 22, 2014 at 07:16:47PM -0700, Tom Herbert wrote:
[...]
Alexei, I believe you said previously said that SW should not dictate
HW models. I agree with this, but also believe the converse is true--
HW shouldn't dictate SW model. This is real
On 09/22/14 21:36, John Fastabend wrote:
n-tuple has some deficiencies,
- its not possible to get the capabilities to learn what
fields are supported by the device, what actions, etc.
- its ioctl based so we have to poll the device
- only supports a single table, where w
On 09/23/14 at 12:11am, Andy Gospodarek wrote:
> There are clearly some that are most interested in how an eSwitch on an
> SR-IOV capable NIC be controlled can provide traditional forwarding help
> as well as offload the various technologies they hope to terminate
> at/inside their endpoint (host/g
On 09/22/14 at 07:16pm, Tom Herbert wrote:
> Turn on UDP RSS on the device and I bet you'll see those differences
> go away! Once we moved to UDP encapsulation, there's really little
> value in looking at inner headers for RSS or ECMP, this should be
> sufficient. Sure someone might want to parse t
On 09/22/14 at 03:40pm, Tom Herbert wrote:
> On Mon, Sep 22, 2014 at 3:17 PM, Thomas Graf wrote:
> > What makes stateful offload interesting to me is that the final
> > desintation of a packet is known at RX and can be redirected to a
> > queue or VF. This allows to build packet batches on shared
On 09/22/14 at 06:36pm, John Fastabend wrote:
> n-tuple has some deficiencies,
>
> - its not possible to get the capabilities to learn what
> fields are supported by the device, what actions, etc.
>
> - its ioctl based so we have to poll the device
>
> - only supports a
On Mon, Sep 22, 2014 at 07:16:47PM -0700, Tom Herbert wrote:
[...]
>
> Alexei, I believe you said previously said that SW should not dictate
> HW models. I agree with this, but also believe the converse is true--
> HW shouldn't dictate SW model. This is really why I'm raising the
> question of wha
On Mon, Sep 22, 2014 at 7:16 PM, Tom Herbert wrote:
> On Mon, Sep 22, 2014 at 6:54 PM, Alexei Starovoitov
> wrote:
>> On Mon, Sep 22, 2014 at 8:10 AM, Tom Herbert wrote:
>>> On Mon, Sep 22, 2014 at 1:13 AM, Thomas Graf wrote:
On 09/20/14 at 03:50pm, Alexei Starovoitov wrote:
> I think
On Mon, Sep 22, 2014 at 6:54 PM, Alexei Starovoitov
wrote:
> On Mon, Sep 22, 2014 at 8:10 AM, Tom Herbert wrote:
>> On Mon, Sep 22, 2014 at 1:13 AM, Thomas Graf wrote:
>>> On 09/20/14 at 03:50pm, Alexei Starovoitov wrote:
I think HW should not be limited by SW abstractions whether
thes
On Mon, Sep 22, 2014 at 8:10 AM, Tom Herbert wrote:
> On Mon, Sep 22, 2014 at 1:13 AM, Thomas Graf wrote:
>> On 09/20/14 at 03:50pm, Alexei Starovoitov wrote:
>>> I think HW should not be limited by SW abstractions whether
>>> these abstractions are called flows, n-tuples, bridge or else.
>>> Rea
On 09/22/2014 04:07 PM, Tom Herbert wrote:
On Mon, Sep 22, 2014 at 3:53 PM, Thomas Graf wrote:
On 09/22/14 at 03:40pm, Tom Herbert wrote:
On Mon, Sep 22, 2014 at 3:17 PM, Thomas Graf wrote:
What makes stateful offload interesting to me is that the final
desintation of a packet is known at RX
On Mon, Sep 22, 2014 at 3:53 PM, Thomas Graf wrote:
> On 09/22/14 at 03:40pm, Tom Herbert wrote:
>> On Mon, Sep 22, 2014 at 3:17 PM, Thomas Graf wrote:
>> > What makes stateful offload interesting to me is that the final
>> > desintation of a packet is known at RX and can be redirected to a
>> >
On 09/22/14 at 03:40pm, Tom Herbert wrote:
> On Mon, Sep 22, 2014 at 3:17 PM, Thomas Graf wrote:
> > What makes stateful offload interesting to me is that the final
> > desintation of a packet is known at RX and can be redirected to a
> > queue or VF. This allows to build packet batches on shared
On Mon, Sep 22, 2014 at 3:17 PM, Thomas Graf wrote:
> On 09/22/14 at 08:10am, Tom Herbert wrote:
>> Thomas, can you (or someone else) quantify what the host case is. I
>> suppose there may be merit in using a switch on NIC for kernel bypass
>> scenarios, but I'm still having a hard time understand
On 09/22/14 at 08:10am, Tom Herbert wrote:
> Thomas, can you (or someone else) quantify what the host case is. I
> suppose there may be merit in using a switch on NIC for kernel bypass
> scenarios, but I'm still having a hard time understanding how this
> could be integrated into the host stack wit
On Mon, Sep 22, 2014 at 1:13 AM, Thomas Graf wrote:
> On 09/20/14 at 03:50pm, Alexei Starovoitov wrote:
>> I think HW should not be limited by SW abstractions whether
>> these abstractions are called flows, n-tuples, bridge or else.
>> Really looking forward to see "device reporting the headers as
On 09/22/14 03:53, Jiri Pirko wrote:
Jamal, would you please give us some examples on how to use tc to work
with flows? I have a feeling that you see something other people does not.
I will be a little verbose so as to avoid knowledge assumption.
Lets talk about tc classifier/action subsystem
On 09/20/14 at 03:50pm, Alexei Starovoitov wrote:
> I think HW should not be limited by SW abstractions whether
> these abstractions are called flows, n-tuples, bridge or else.
> Really looking forward to see "device reporting the headers as
> header fields (len, offset) and the associated parse gr
Sat, Sep 20, 2014 at 01:32:30PM CEST, j...@mojatatu.com wrote:
>On 09/20/14 07:01, Thomas Graf wrote:
>
>>Nothing speaks against having such a tc classifier. In fact, having
>>the interface consist of only an embedded Netlink attribute structure
>>would allow for such a classifier in a very straigh
On 9/20/14, 10:38 AM, Jiri Pirko wrote:
Sat, Sep 20, 2014 at 07:21:10PM CEST, sfel...@cumulusnetworks.com wrote:
On Sep 20, 2014, at 5:51 AM, Roopa Prabhu wrote:
On 9/20/14, 1:10 AM, Scott Feldman wrote:
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu
wrote:
On 9/19/14, 8:49 AM, Jiri Pirko w
On Sat, Sep 20, 2014 at 3:53 AM, Thomas Graf wrote:
> On 09/20/14 at 10:14am, Jiri Pirko wrote:
>> Sat, Sep 20, 2014 at 12:12:12AM CEST, john.r.fastab...@intel.com wrote:
>> >I was considering a slightly different approach where the
>> >device would report via netlink the fields/actions it
>> >sup
Sat, Sep 20, 2014 at 07:21:10PM CEST, sfel...@cumulusnetworks.com wrote:
>
>On Sep 20, 2014, at 5:51 AM, Roopa Prabhu wrote:
>
>> On 9/20/14, 1:10 AM, Scott Feldman wrote:
>>> On Sep 19, 2014, at 8:41 PM, Roopa Prabhu
>>> wrote:
>>>
>>>
On 9/19/14, 8:49 AM, Jiri Pirko wrote:
> F
On Sep 20, 2014, at 5:51 AM, Roopa Prabhu wrote:
> On 9/20/14, 1:10 AM, Scott Feldman wrote:
>> On Sep 19, 2014, at 8:41 PM, Roopa Prabhu
>> wrote:
>>
>>
>>> On 9/19/14, 8:49 AM, Jiri Pirko wrote:
>>>
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com
wrote:
> On 0
On 9/20/14, 1:10 AM, Scott Feldman wrote:
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu wrote:
On 9/19/14, 8:49 AM, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
On 09/19/14 09:49, Jiri Pirko wrote:
This patch exposes switchdev API using generic Netlink.
Examp
On 9/20/14, 1:09 AM, Jiri Pirko wrote:
Sat, Sep 20, 2014 at 05:41:16AM CEST, ro...@cumulusnetworks.com wrote:
On 9/19/14, 8:49 AM, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
On 09/19/14 09:49, Jiri Pirko wrote:
This patch exposes switchdev API using gener
On 09/20/14 07:51, Thomas Graf wrote:
I fail to see the connection. You can use switch vendor SDK no matter
how we define the kernel APIs. They already exist and have been
designed in a way to be completely indepenedent from the kernel.
Are you referring to vendor specific decisions in user spa
On 09/20/14 at 07:32am, Jamal Hadi Salim wrote:
> I am sorry to have tied the two together. Maybe not OVS but the approach
> described is heaven for vendor SDKs.
I fail to see the connection. You can use switch vendor SDK no matter
how we define the kernel APIs. They already exist and have been
de
On 09/20/14 07:01, Thomas Graf wrote:
Nothing speaks against having such a tc classifier. In fact, having
the interface consist of only an embedded Netlink attribute structure
would allow for such a classifier in a very straight forward way.
That doesn't mean everybody should be forced to use t
On 09/20/14 at 06:19am, Jamal Hadi Salim wrote:
> The ovs guys are against this and now no *api exists*?
> Write a 15 tuple classifier tc classifier and use it. I will be more
> than happy to help you. I will get to it when we have basics L2 working
> on real devices.
Nothing speaks against having
On 09/20/14 at 10:14am, Jiri Pirko wrote:
> Sat, Sep 20, 2014 at 12:12:12AM CEST, john.r.fastab...@intel.com wrote:
> >I was considering a slightly different approach where the
> >device would report via netlink the fields/actions it
> >supported rather than creating pre-defined enums for every
> >
On 09/20/14 04:10, Scott Feldman wrote:
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu wrote:
Existing rtnetlink isn’t available to swdev without some kind of snooping the
echoes from the various kernel components
(bridge, fib, etc).
You have made this claim before Scott and I am still not f
On 09/20/14 04:17, Jiri Pirko wrote:
Yes, that I say. It is needed for flow manipulation, because such api does
not exist.
Come on Jiri!
The ovs guys are against this and now no *api exists*?
Write a 15 tuple classifier tc classifier and use it. I will be more
than happy to help you. I will ge
Sat, Sep 20, 2014 at 07:39:51AM CEST, f.faine...@gmail.com wrote:
>On 09/19/14 15:18, Jamal Hadi Salim wrote:
>>On 09/19/14 18:12, John Fastabend wrote:
>>>On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
On 09/19/14 11:49, Jiri Pirko wrote:
>Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojata
Sat, Sep 20, 2014 at 12:18:02AM CEST, j...@mojatatu.com wrote:
>On 09/19/14 18:12, John Fastabend wrote:
>>On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
>>>On 09/19/14 11:49, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
>>>
>Is this just a temporary tes
Sat, Sep 20, 2014 at 12:12:12AM CEST, john.r.fastab...@intel.com wrote:
>On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
>> On 09/19/14 11:49, Jiri Pirko wrote:
>>> Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
>>
Is this just a temporary test tool? Otherwise i dont see reaso
On Sep 19, 2014, at 8:41 PM, Roopa Prabhu wrote:
> On 9/19/14, 8:49 AM, Jiri Pirko wrote:
>> Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
>>> On 09/19/14 09:49, Jiri Pirko wrote:
This patch exposes switchdev API using generic Netlink.
Example userspace utility is here
Sat, Sep 20, 2014 at 05:41:16AM CEST, ro...@cumulusnetworks.com wrote:
>On 9/19/14, 8:49 AM, Jiri Pirko wrote:
>>Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
>>>On 09/19/14 09:49, Jiri Pirko wrote:
This patch exposes switchdev API using generic Netlink.
Example userspace u
On 09/19/14 15:18, Jamal Hadi Salim wrote:
On 09/19/14 18:12, John Fastabend wrote:
On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
On 09/19/14 11:49, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
Is this just a temporary test tool? Otherwise i dont see re
On 09/19/14 15:12, John Fastabend wrote:
On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
On 09/19/14 11:49, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
Is this just a temporary test tool? Otherwise i dont see reason
for its existence (or the API that it f
On 9/19/14, 8:49 AM, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
On 09/19/14 09:49, Jiri Pirko wrote:
This patch exposes switchdev API using generic Netlink.
Example userspace utility is here:
https://github.com/jpirko/switchdev
Is this just a temporary te
On 09/19/14 18:12, John Fastabend wrote:
On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
On 09/19/14 11:49, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
Is this just a temporary test tool? Otherwise i dont see reason
for its existence (or the API that it f
On 09/19/2014 10:57 AM, Jamal Hadi Salim wrote:
> On 09/19/14 11:49, Jiri Pirko wrote:
>> Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
>
>>> Is this just a temporary test tool? Otherwise i dont see reason
>>> for its existence (or the API that it feeds on).
>>
>> Please read the
On 09/19/14 11:49, Jiri Pirko wrote:
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
Is this just a temporary test tool? Otherwise i dont see reason
for its existence (or the API that it feeds on).
Please read the conversation I had with Pravin and Jesse in v1 thread.
Long sto
Fri, Sep 19, 2014 at 05:25:48PM CEST, j...@mojatatu.com wrote:
>On 09/19/14 09:49, Jiri Pirko wrote:
>>This patch exposes switchdev API using generic Netlink.
>>Example userspace utility is here:
>>https://github.com/jpirko/switchdev
>>
>
>Is this just a temporary test tool? Otherwise i dont see re
On 09/19/14 09:49, Jiri Pirko wrote:
This patch exposes switchdev API using generic Netlink.
Example userspace utility is here:
https://github.com/jpirko/switchdev
Is this just a temporary test tool? Otherwise i dont see reason
for its existence (or the API that it feeds on).
cheers,
jamal
_
This patch exposes switchdev API using generic Netlink.
Example userspace utility is here:
https://github.com/jpirko/switchdev
Signed-off-by: Jiri Pirko
---
MAINTAINERS | 1 +
include/uapi/linux/switchdev.h| 113 ++
net/switchdev/Kconfig | 11 +
n
52 matches
Mail list logo
