e SW Conntrack perf (Mark Gray)
> --Bhanu and Antonio will start looking at this start of 2017
> HW acceleration:
>
> * Share use cases where conntrack is not needed (John Fastabend)
First get some basics out. I tend to break connection tracking into
at least two broad categories.
(a
On 03/05/2015 05:16 AM, Jamal Hadi Salim wrote:
On 03/05/15 07:37, Jamal Hadi Salim wrote:
On 03/05/15 02:39, John Fastabend wrote:
Would kernel boot/module options passed to the driver not suffice?
That implies a central authority that decides what these table size
slicing looks like
via an API provided by the
kernel. In particular my working assumption is that the Flow API proposed
by John Fastabend[3] may be used to add flows to hardware. While the
existing netlink API may be used to add flows to the kernel datapath.
Doesn't this imply two entities
in the datapath.
But rather limits this discussion to a mode where offloads are managed
from user-space.
* That Open vSwitch may add flows to hardware via an API provided by the
kernel. In particular my working assumption is that the Flow API
proposed
by John Fastabend[3] may be used
On 03/04/2015 10:42 PM, David Miller wrote:
From: Tom Herbert therb...@google.com
Date: Wed, 4 Mar 2015 21:20:41 -0800
On Wed, Mar 4, 2015 at 9:00 PM, David Miller da...@davemloft.net wrote:
From: John Fastabend john.fastab...@gmail.com
Date: Wed, 04 Mar 2015 17:54:54 -0800
I think a set
the
code. Also it seems like a reasonable approach to me any thoughts?
.John
--
John Fastabend Intel Corporation
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
overall to support the above anyways.
We could port the ethtool ops over to the new interface to
simplify drivers.
.John
--
John Fastabend Intel Corporation
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
I had with Pravin and Jesse in v1 thread.
Long story short they like to have the api separated from ovs datapath
so ovs daemon can use it to directly communicate with driver. Also John
Fastabend requested a way to work with driver flows without using ovs -
that was the original reason I created
sw_flow_actions {
+ unsigned count;
+ struct sw_flow_action actions[0];
+};
+
+struct sw_flow {
+ struct sw_flow_key key;
+ struct sw_flow_key unmasked_key;
+ struct sw_flow_mask *mask;
+ struct sw_flow_actions *actions;
+};
+
--
John Fastabend Intel Corporation
with additional patches
if you want. I could help but it will be another week or so
before I have some time. The biggest issue IMO is the lack of
capabilities queries.
Thanks,
John
--
John Fastabend Intel Corporation
___
dev mailing list
dev
;
}
}
[...]
Thanks,
John
--
John Fastabend Intel Corporation
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
to
read. I'm the squemish one in the audience here.
.John
--
John Fastabend Intel Corporation
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On 08/23/2014 07:51 AM, Thomas Graf wrote:
On 08/23/14 at 11:24am, Jiri Pirko wrote:
Sat, Aug 23, 2014 at 12:53:34AM CEST, sfel...@cumulusnetworks.com wrote:
On Aug 22, 2014, at 12:39 PM, John Fastabend john.fastab...@gmail.com wrote:
- this requires OVS to be loaded to work. If all I want
otherwise I doubt we will get it
consistently right across drivers. There could for example be
somewhat strange devices with virtual functions hanging off of the
switch.
Thanks,
John
--
John Fastabend Intel Corporation
___
dev mailing list
dev
on that.
.John
--
John Fastabend Intel Corporation
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
the hw/sw bitmask (or
maybe a better implementation of that idea) then this should work
for the stuff I'm looking at. I want to try and get it working on
the i40e driver as a fdir replacement but it might take me a bit
to get to it.
Thanks,
John
--
John Fastabend Intel Corporation
netlink so I can write my policy in user space and not require
OVS. If OVS wants to support a mode where it does this automagically
it can support it in userspace and the kernel side does not need to
change.
Thanks,
John
--
John Fastabend Intel Corporation
On 4/24/2014 8:46 AM, Jiri Pirko wrote:
Thu, Apr 24, 2014 at 04:54:19PM CEST, john.fastab...@gmail.com wrote:
On 04/17/2014 05:15 AM, Jiri Pirko wrote:
Benefit from the possibility to work with flows in switch devices and
use the swdev api to offload flow datapath.
Signed-off-by: Jiri Pirko
On 11/30/2011 5:21 AM, Eric Dumazet wrote:
Le mercredi 30 novembre 2011 à 08:14 -0500, jamal a écrit :
On Wed, 2011-11-30 at 15:00 +0800, Herbert Xu wrote:
The other factor I considered is scalability. The OVS code as is
is not really friendly to SMP/NUMA scalability (but as Eric pointed,
On 11/23/2011 5:44 AM, Jamal Hadi Salim wrote:
On Wed, 2011-11-23 at 13:55 +0100, Eric Dumazet wrote:
Currently thinking about it. I was also waiting Tom Herbert BQL patches.
Excellent. I can test when you have something.
Several people are interested, and John Fastabend told me he plans
On 11/22/2011 5:45 PM, Jamal Hadi Salim wrote:
On Tue, 2011-11-22 at 15:11 -0800, Jesse Gross wrote:
As you mention, one of the biggest benefits of Open vSwitch is how
simple the kernel portions are (it's less than 6000 lines).
I said that was the reason _you_ were using to justify
On 11/19/2011 3:06 PM, Jesse Gross wrote:
On Fri, Nov 18, 2011 at 9:30 PM, John Fastabend
john.r.fastab...@intel.com wrote:
On 11/18/2011 3:12 PM, Jesse Gross wrote:
+ */
+enum ovs_frag_type {
+ OVS_FRAG_TYPE_NONE,
+ OVS_FRAG_TYPE_FIRST,
+ OVS_FRAG_TYPE_LATER
On 11/18/2011 3:12 PM, Jesse Gross wrote:
Open vSwitch is a multilayer Ethernet switch targeted at virtualized
environments. In addition to supporting a variety of features
expected in a traditional hardware switch, it enables fine-grained
programmatic extension and flow-based control of the
23 matches
Mail list logo
