From: Eric Dumazet
Date: Mon, 28 Nov 2011 16:25:02 +0100
> Current SFB double hashing is not fulfilling SFB theory, if two flows
> share same rxhash value.
>
> Using skb_flow_dissect() permits to really have better hash dispersion,
> and get tunnelling support as well.
>
> Double hashing point
From: Eric Dumazet
Date: Mon, 28 Nov 2011 16:24:18 +0100
> Instead of using a custom flow dissector, use skb_flow_dissect() and
> benefit from tunnelling support.
>
> This lack of tunnelling support was mentioned by Dan Siemon.
>
> Signed-off-by: Eric Dumazet
Applied.
From: Eric Dumazet
Date: Mon, 28 Nov 2011 16:23:23 +0100
> No functional changes.
>
> This uses the code we factorized in skb_flow_dissect()
>
> Signed-off-by: Eric Dumazet
Applied.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mai
From: Eric Dumazet
Date: Mon, 28 Nov 2011 16:22:18 +0100
> We use at least two flow dissectors in network stack, with known
> limitations and code duplication.
>
> Introduce skb_flow_dissect() to factorize this, highly inspired from
> existing dissector from __skb_get_rxhash()
>
> Note : We ext
From: Dimitris Michailidis
Date: Mon, 28 Nov 2011 08:25:39 -0800
>> +bool skb_flow_dissect(const struct sk_buff *skb, struct flow_keys
>> *flow)
>> +{
>> +int poff, nhoff = skb_network_offset(skb);
>> +u8 ip_proto;
>> +u16 proto = skb->protocol;
>
> __be16 instead of u16 for proto?
Sounds fine to me. I've changed the comment and will push this soon.
Ethan
On Mon, Nov 28, 2011 at 15:40, Ben Pfaff wrote:
> On Mon, Nov 28, 2011 at 02:43:15PM -0800, Ethan Jackson wrote:
>> In an effort to simplify ofproto-dpif, this commit moves the
>> definition of commit_odp_actions() to od
On Mon, Nov 28, 2011 at 02:43:15PM -0800, Ethan Jackson wrote:
> In an effort to simplify ofproto-dpif, this commit moves the
> definition of commit_odp_actions() to odp-util.
I think that we could improve the comment on commit_odp_actions().
Something like this:
If any of the flow key data t
Looks good, thank you.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
It might be nice to actually install these, but there's no standard place
to install them. Nevertheless, it's nice to have the target around
because it shows how to generate PDFs. It should make it easier for me to
regenerate the PDF for ovs-vswitchd.conf.db(5) on openvswitch.org, for
example.
R
On Mon, Nov 28, 2011 at 05:21:13PM -0500, Jamal Hadi Salim wrote:
> On Mon, 2011-11-28 at 08:01 -0800, Ben Pfaff wrote:
>
> > Regarding OpenFlow rate limiting, in addition to Martin's response, Open
> > vSwitch has implemented controller rate limiting since day one. It is
> > documented in ovs-vs
On Mon, 2011-11-28 at 10:44 -0800, Justin Pettit wrote:
> I realize you chair an IETF standard with overlapping goals with
> OpenFlow (ForCES), so you may have strong opinions about its design.
Yes, I do have strong opinions not really related to ForCES more towards
Linux. If i was to put ForCES
In an effort to simplify ofproto-dpif, this commit moves the
definition of commit_odp_actions() to odp-util.
---
lib/odp-util.c | 160 +++
lib/odp-util.h |3 +
ofproto/ofproto-dpif.c | 163 +--
---
ofproto/ofproto-dpif.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index 1b7bc44..88032bf 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -4308,7 +4308,6 @@ flood_packets(struct action_xlate_ctx *c
On Mon, 2011-11-28 at 10:34 -0800, Justin Pettit wrote:
> On Nov 25, 2011, at 5:11 PM, Jamal Hadi Salim wrote:
>
> Are you talking about ASICs on NICs?
I am indifferent - looking at it entirely from a control
perspective. i.e if i do "ip link blah down" on a port
i want that to work with zero
On Mon, 2011-11-28 at 08:01 -0800, Ben Pfaff wrote:
> Regarding OpenFlow rate limiting, in addition to Martin's response, Open
> vSwitch has implemented controller rate limiting since day one. It is
> documented in ovs-vswitchd.conf.db(5):
Ok, I think thats a good start. My experience says just
On Thu, Nov 10, 2011 at 09:14:50AM -0800, Ben Pfaff wrote:
> On Thu, Nov 10, 2011 at 06:04:07PM +0900, Simon Horman wrote:
> > On Wed, Nov 09, 2011 at 08:14:36PM -0800, Ben Pfaff wrote:
> > > On Thu, Nov 10, 2011 at 10:20:24AM +0900, Simon Horman wrote:
> > > > On Wed, Nov 09, 2011 at 01:19:42PM -0
Reported-by: Jesse Gross
---
Does this correctly explain the issue?
Thanks,
Ben.
diff --git a/utilities/ovs-vlan-bugs.man b/utilities/ovs-vlan-bugs.man
index bdca8fc..1e62d16 100644
--- a/utilities/ovs-vlan-bugs.man
+++ b/utilities/ovs-vlan-bugs.man
@@ -6,6 +6,11 @@ the extracted tag. Drivers
Thank you, I will push this soon.
On Mon, Nov 28, 2011 at 01:02:42PM -0800, Ethan Jackson wrote:
> Looks good to me.
>
> Ethan
>
> On Wed, Nov 16, 2011 at 14:39, Ben Pfaff wrote:
> > Multiple-clause conditions in OVSDB operations with "where" clauses are
> > supposed to be conjunctions, that is
Looks good to me.
Ethan
On Wed, Nov 16, 2011 at 14:39, Ben Pfaff wrote:
> Multiple-clause conditions in OVSDB operations with "where" clauses are
> supposed to be conjunctions, that is, the condition is true only if every
> clause is true. In fact, the implementation only checked a single claus
Thank you. I will push this soon.
On Mon, Nov 28, 2011 at 11:18:23AM -0800, Ethan Jackson wrote:
> Looks good.
>
> Ethan
>
> On Wed, Nov 23, 2011 at 12:15, Ben Pfaff wrote:
> > On one machine, "/etc/init.d/openvswitch-switch start" failed to start
> > with:
> >
> > ? ovs-vswitchd: fork child f
Thank you. I pushed this.
On Mon, Nov 28, 2011 at 11:08:21AM -0800, Ethan Jackson wrote:
> Looks good.
>
> Ethan
>
> On Mon, Nov 14, 2011 at 10:11, Ben Pfaff wrote:
> > The Netlink code in the Linux kernel has been willing to choose unique
> > Netlink pids for userspace sockets since at least
Looks good.
Ethan
On Wed, Nov 23, 2011 at 12:15, Ben Pfaff wrote:
> On one machine, "/etc/init.d/openvswitch-switch start" failed to start
> with:
>
> ovs-vswitchd: fork child failed to signal startup (Success)
> Starting ovs-vswitchd ... failed!
>
> "strace" revealed that the fork child was
Looks good.
Ethan
On Mon, Nov 14, 2011 at 10:11, Ben Pfaff wrote:
> The Netlink code in the Linux kernel has been willing to choose unique
> Netlink pids for userspace sockets since at least 2.4.36 and probably
> earlier. There's no value in choosing them ourselves.
>
> This simplifies the code
> Subject: Re: [ovs-dev] Issues with openflow protocol WAS(RE: [GIT PULL
> v2] Open vSwitch
>
> On Nov 28, 2011, at 6:07 AM, Jamal Hadi Salim wrote:
>
> > On Mon, 2011-11-28 at 13:54 +, Fischer, Anna wrote:
> >
> >> Yes, I mentioned this months ago, and I am surprised this critical
> >> issue
> Subject: Re: [ovs-dev] [GIT PULL v2] Open vSwitch
>
> On Mon, Nov 28, 2011 at 01:54:16PM +, Fischer, Anna wrote:
> > Yes, I mentioned this months ago, and I am surprised this critical
> > issue has never been picked up on and addressed. With a flaw like
> this
> > there is no chance this com
On Nov 28, 2011, at 6:07 AM, Jamal Hadi Salim wrote:
> On Mon, 2011-11-28 at 13:54 +, Fischer, Anna wrote:
>
>> Yes, I mentioned this months ago, and I am surprised this critical
>> issue has never been picked up on and addressed. With a flaw like
>> this there is no chance this component c
On Thu, Nov 24, 2011 at 11:05:40AM -0800, Justin Pettit wrote:
> On Nov 22, 2011, at 3:27 PM, Ben Pfaff wrote:
>
> > +/* Performs periodic activity required by 'ofproto' that needs to be done
> > + * with the least possible latency.
> > + *
> > + * It makes sense to call this function a couple of
On Nov 25, 2011, at 5:11 PM, Jamal Hadi Salim wrote:
>> A big difficulty is finding an appropriate hardware abstraction. I've
>> worked on porting
>> Open vSwitch to a few different vendors' switching ASICs, and they've all
>> looked quite
>> different from each other. Even within a vendor,
On Thu, Nov 24, 2011 at 09:28:38AM -0800, Justin Pettit wrote:
> On Nov 22, 2011, at 3:12 PM, Ben Pfaff wrote:
>
> > /* Upcall messages. */
> > struct nl_sock *upcall_socks[N_UPCALL_SOCKS];
> > -int last_read_upcall;
> > +uint32_t nonempty_socks;
>
> I think it would be helpful to
On Mon, Nov 28, 2011 at 04:19:07PM +0100, Gaetano Catalli wrote:
> the following is a snippet of code taken from the
> netdev_linux_create_system() function in lib/netdev-linux.c. It wants
> to attach a callback to interfaces status change events. The notifier
> is unique for all devices so it is c
On 11/28/2011 07:22 AM, Eric Dumazet wrote:
We use at least two flow dissectors in network stack, with known
limitations and code duplication.
Introduce skb_flow_dissect() to factorize this, highly inspired from
existing dissector from __skb_get_rxhash()
Note : We extensively use skb_header_poi
On Mon, Nov 28, 2011 at 01:54:16PM +, Fischer, Anna wrote:
> Yes, I mentioned this months ago, and I am surprised this critical
> issue has never been picked up on and addressed. With a flaw like this
> there is no chance this component can be used in any serious
> virtualization deployment whe
On Mon, Nov 28, 2011 at 09:02:34AM -0500, Jamal Hadi Salim wrote:
> On Mon, 2011-11-28 at 21:04 +0800, Herbert Xu wrote:
> > However, what's more worrying for me right now is the gaping
> > DoS opportunities that exist in the patch as is.
> >
> > In particular, the whole design principle of puntin
This is a common misunderstanding about OpenFlow. It does not require
the first packet of each flow to go to the controller.
I am reading this to mean that the switch CPU will resolve things?
Typically those tend to be tiny cpus.
No, no datapath traffic leaves the switching chip. Generally
co
On Mon, 2011-11-28 at 07:27 -0800, Martin Casado wrote:
> This is a common misunderstanding about OpenFlow. It does not require
> the first packet of each flow to go to the controller.
I am reading this to mean that the switch CPU will resolve things?
Typically those tend to be tiny cpus.
>
However, what's more worrying for me right now is the gaping
DoS opportunities that exist in the patch as is.
In particular, the whole design principle of punting all new
flows to user-space is an excellent way of attacking the system.
Indeed this is an issue with openflow in general.
The gene
Current SFB double hashing is not fulfilling SFB theory, if two flows
share same rxhash value.
Using skb_flow_dissect() permits to really have better hash dispersion,
and get tunnelling support as well.
Double hashing point was mentioned by Florian Westphal
Signed-off-by: Eric Dumazet
---
net/
Instead of using a custom flow dissector, use skb_flow_dissect() and
benefit from tunnelling support.
This lack of tunnelling support was mentioned by Dan Siemon.
Signed-off-by: Eric Dumazet
---
net/sched/cls_flow.c | 180 ++---
1 file changed, 48 insertions
No functional changes.
This uses the code we factorized in skb_flow_dissect()
Signed-off-by: Eric Dumazet
---
net/core/dev.c | 125 +--
1 file changed, 14 insertions(+), 111 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 8afb244..96
We use at least two flow dissectors in network stack, with known
limitations and code duplication.
Introduce skb_flow_dissect() to factorize this, highly inspired from
existing dissector from __skb_get_rxhash()
Note : We extensively use skb_header_pointer(), this permits us to not
touch skb at al
Le vendredi 25 novembre 2011 à 14:02 +0100, Eric Dumazet a écrit :
> cls_flow is not complete, since it doesnt handle tunnels for example.
>
> It calls a 'partial flow classifier' to find each needed element, one by
> one.
> (adding tunnel decap would need to perform this several time for each
>
Hi all,
the following is a snippet of code taken from the
netdev_linux_create_system() function in lib/netdev-linux.c. It wants
to attach a callback to interfaces status change events. The notifier
is unique for all devices so it is created when the first port is
attached to the switch and deleted
On Mon, Nov 28, 2011 at 01:54:16PM +, Fischer, Anna wrote:
>
> Yes, I mentioned this months ago, and I am surprised this critical issue has
> never been picked up on and addressed. With a flaw like this there is no
> chance this component can be used in any serious virtualization deployment
On Mon, 2011-11-28 at 13:54 +, Fischer, Anna wrote:
> Yes, I mentioned this months ago, and I am surprised this critical
> issue has never been picked up on and addressed. With a flaw like
> this there is no chance this component can be used in any serious
> virtualization deployment where
On Mon, 2011-11-28 at 21:04 +0800, Herbert Xu wrote:
> You're right, a new classifier for the hash table would be the
> best option.
>
> > I cant find one - you may. After staring at the code, I am also now
> > questioning if the existing bridge code couldnt have been re-used with
> > some small
> Subject: Re: [GIT PULL v2] Open vSwitch
>
> On Wed, Nov 23, 2011 at 07:22:56AM -0500, jamal wrote:
> >
> > For a classifier, u32 or em matches would do the job - but they may
> > need a wrapper around it in user space; so from a usability pov, it
> > would make sense to have a new classifier th
On Wed, Nov 23, 2011 at 07:22:56AM -0500, jamal wrote:
>
> For a classifier, u32 or em matches would do the job - but they may
> need a wrapper around it in user space; so from a usability pov, it
> would make sense to have a new classifier that is specific to them.
> All the VLAN actions could go
You are receiving this email because we wish you to use our digital photo
editing services.
Digital Photo Editing Services :
We are a China based Imaging Professionals. We offer basic and advanced digital
photo Editing services and solutions like photo Cutout, morphological photo
Editing, phot
48 matches
Mail list logo
