On Fri, Sep 12, 2014 at 05:55:18PM +0530, Rishi Bamba wrote:
1. Currently we have modified ofp11_flow_mod in openflow-1.1.h for
addition of ovs_be16 importance parameter.
Query: Do we need to create ofp14_flow_mod as the structure is
currently not present in openflow-1.4.h or the enhancement
Acked-by: Ethan Jackson et...@nicira.com
On Thu, Sep 11, 2014 at 3:03 PM, Joe Stringer joestrin...@nicira.com wrote:
The datapath max_idle value determines how long to wait before deleting
an idle datapath flow when operating below the flow_limit. This patch
increases the max_idle to 10
Thanks, applied to master.
On 15 September 2014 09:41, Ethan Jackson et...@nicira.com wrote:
Acked-by: Ethan Jackson et...@nicira.com
On Thu, Sep 11, 2014 at 3:03 PM, Joe Stringer joestrin...@nicira.com
wrote:
The datapath max_idle value determines how long to wait before deleting
an
The original message was received at Mon, 15 Sep 2014 08:53:14 +0700 from
openvswitch.org [216.251.140.70]
- The following addresses had permanent fatal errors -
dev@openvswitch.org
- Transcript of session follows -
... while talking to openvswitch.org.:
554 5.0.0 Service
Patches #1-4 have been reviewed and Ack'd by Ben, which I have held out from
pushing upstream as they are only useful with the rest of the series. The
remaining patches are yet to be reviewed.
This series is also made available here to assist review:
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Ben Pfaff b...@nicira.com
---
v4-v5: No change.
v3: Rebase.
v2: Call ovsrcu_quiesce() unconditionally.
RFC: Initial Post.
---
ofproto/ofproto-dpif-upcall.c | 61 ++---
1 file changed, 33
Currently, udpif_keys are protected during revalidator_sweep__() as only
one thread accesses the ukey at a time. This is ensured using barriers:
all revalidators will be in the GC phase, so they will only access their
own ukey collection.
A future patch will change the access patterns to allow
An upcoming patch will change the access patterns for ukey maps to
increase the number of writers, and shift write-access from revalidator
threads to upcall handler threads. As such, it no longer makes sense to
tie these maps to revalidators in a 1:1 relationship.
This patch separates the ukey
Future patches will make use of the 'struct dump_op' in a broader sense,
so this patch renames it to make things a bit clearer.
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Ben Pfaff b...@nicira.com
---
v4-v5: No change.
v3: Rebase.
v2: No change.
RFC: First post.
---
Currently, when a revalidator thread first dumps a flow, it creates a
'udpif_key' object and caches a copy of a kernel flow key. This allows
us to perform lookups in the classifier to attribute stats and validate
the correctness of the datapath flow.
This patch sets up this cache from the handler
This allows us to ignore most fields of a flow_dump, requiring only the
flow key for looking up the ukey. Fetching flows can also be avoided in
the corner case where a flow is missed from a dump but revalidation is
required.
A future patch will modify the datapath interface to make these cached
One of the limiting factors on the number of flows that can be supported
in the datapath is the overhead of assembling flow dump messages in the
datapath. This patch adds a new alternative to dumping the key, mask and
actions from the datapath, which is a 128-bit unique identifier for the
flow.
If a datapath is created with the flag OVS_DP_F_INDEX_BY_UID, then an
additional table_instance is added to the flow_table, which is indexed
by unique identifiers (UID). This can be manipulated using the flow
key as before, or by using the new UID field. If both are specified,
then UID takes
When handler threads are installing ukeys, they hold the ukey mutex for
the duration of flow setup. If a revalidator thread dumps this flow
while the handler holds the lock, it will attempt to lock it using
ovs_mutex_trylock(), then if it cannot grab the lock, skip the flow.
Attempting to lock on
We previously counted flows that have been installed during the current
dump as duplicates, rather than recognising them as new flows. This
patch separates the counters out for these two cases.
Signed-off-by: Joe Stringer joestrin...@nicira.com
---
v5: No change.
v4: Initial post.
---
Thanks Nithin,
This netdev check on windows, I understand, would translate to a km-um /
netlink communication by which it will be checked if the hyper-v switch does
have a port with friendly name X.
The only thing that remains is to be sure that when that vnic disconnects, a
vport delete will
Thanks for the fix, I pushed this to master.
On 13 September 2014 05:35, Daniele Di Proietto ddiproie...@vmware.com
wrote:
--enable-dummy was useless anyway for ovsdb-server. Now it is an error to
pass
it.
Signed-off-by: Daniele Di Proietto ddiproie...@vmware.com
---
utilities/ovs-dev.py
I meant in the sense, if it is necessary. AFAIK, the IO pending can only happen
in non-dump operations (and here, non-dump netlink pids).
Therefore, I don't know if it is really useful to FreeDumpState in a pending IO
cancel callback function. Perhaps an ASSERT to make sure the dump state is
I have a question here,
is a file HANDLE normally used by only one userspace thread at a time (so that
if you have multiple threads, each thread will have its own unique file
HANDLEs), or each thread may use the file HANDLEs opened by other threads?
Thanks,
Sam
Although I reviewed and applied #1, I'll leave this one up to Ethan as it's
more relevant to his other proposed changes.
On 13 September 2014 05:35, Daniele Di Proietto ddiproie...@vmware.com
wrote:
If 'configure' with clang fails (this can happen for example if it doesn't
support all the
At first on reading this code, I was wondering why?
Now I think I understand: the function zeroes memory, and must return the ptr
to 'next' item to be filled (which is called tail). Am I correct?
Also, I think it would be nice if you could rename NlBufCopyAtTailUninit -
NlBufZeroAtTailUninit or
Hello Nithin,
Overall, it looks ok.
Very minor things, though:
(OvsDpFillInfo)
o) could you please rename nlWrite into something more boolean-like, like ok
or whatever you prefer?
When I first read that piece of code, I was thinking nlWrite is a ptr returned
by NlMsgPutHead. It confused me for
Hello Nithin,
Thanks a lot again for the review!
-
More than that I was a little concerned about the changes in OvsTunnelTx to
split a TSOed NBL (with multiple NBs) into multiple smaller NBLs. I believe
this would have a performance impact (when we measure it).
The
23 matches
Mail list logo
