Table entries in datapath disappear after short time.
Does they use timer in kernel or other ways?
What is the idle timeout?
If someone know, please let met know where the source code defines.
Thanks.
___
dev mailing list
dev@openvswitch.org
http://open
Junguk Cho
March 24, 2014 at
12:14 AMTable entries in datapath
disappear after short time.Does they use timer in kernel
or other ways?ovs-vswitchd times them
out.What is the idle timeout?It
depends on the version. Older versions defaulted to around five
seconds; newer ones
I used ovs 2.0. So, I think it is 1.5 secs.
Can I adjust timeout values in command line tools?
In addition, "The frequency may be higher or lower depending on load."
What does that mean? Which load did you mean ( the number of current table
entries in datapath?) ?
Thanks.
2014-03-24 1:26 GMT-0
On Sun, Mar 23, 2014 at 11:58 PM, Ben Pfaff wrote:
> I decided that the best thing to do here was to do it myself, so I
> committed your patch 1/5 (with a few adjustments) followed by a patch
> that disables OF1.4 unless one specifies --enable-of14 on the
> ovs-vswitchd command line. This should
Hi All,
We are trying to provide Q-in-Q configuration support to port. For that we have
modified vswitchd/vswitch.xml file.
Could anyone tell us how to test the .xml file changes.
Thanks in advance !
Regards,Deba ___
On Mon, Mar 24, 2014 at 02:32:08PM +0530, Deba Prasad Das wrote:
> We are trying to provide Q-in-Q configuration support to port. For that we
> have modified vswitchd/vswitch.xml file.
> Could anyone tell us how to test the .xml file changes.
The XML file content goes into ovs-vswitchd.conf.db(5)
Acked-by: Jarno Rajahalme
On Mar 21, 2014, at 10:43 AM, Gurucharan Shetty wrote:
> Commit 03fbdf8d9c80a (lib/flow: Retain ODPP_NONE on flow_extract())
> replaced packet metadata initialization function by a macro.
> Visual studio does not like nested structure initialization that
> is done in t
On Mar 21, 2014, at 1:52 PM, Pravin Shelar wrote:
> On Fri, Feb 21, 2014 at 11:41 AM, Jarno Rajahalme
> wrote:
>> Flow SET can set an empty set of actions by not passing any actions.
>> Previously, we assigned the flow's actions pointer to NULL in this
>> case, but we never check for the NULL
Thanks for the review :-)
Pushed to master,
Jarno
On Mar 21, 2014, at 2:14 PM, Pravin Shelar wrote:
> On Fri, Feb 21, 2014 at 11:41 AM, Jarno Rajahalme
> wrote:
>> The 'output' argument of the ovs_nla_put_flow() is the one from which
>> the bits are written to the netlink attributes. For
Thanks for the review :-)
Pushed to master,
Jarno
On Mar 21, 2014, at 2:41 PM, Pravin Shelar wrote:
> On Fri, Feb 21, 2014 at 11:41 AM, Jarno Rajahalme
> wrote:
>> We already extract the TCP flags for the key, might as well use that
>> for stats.
>>
>> Signed-off-by: Jarno Rajahalme
> Lo
On Mon, Mar 24, 2014 at 9:50 AM, Jarno Rajahalme wrote:
>
> On Mar 21, 2014, at 1:52 PM, Pravin Shelar wrote:
>
>> On Fri, Feb 21, 2014 at 11:41 AM, Jarno Rajahalme
>> wrote:
>>> Flow SET can set an empty set of actions by not passing any actions.
>>> Previously, we assigned the flow's actions
'metadata_match' and 'metadata_write' fields are defined as ovs_be64,
but sometimes used and referred to as uint64_t.
Signed-off-by: Jarno Rajahalme
---
lib/ofp-print.c|2 +-
ofproto/ofproto-provider.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/
Looks good, thank you.
On Mar 24, 2014 10:12 AM, "Jarno Rajahalme" wrote:
> 'metadata_match' and 'metadata_write' fields are defined as ovs_be64,
> but sometimes used and referred to as uint64_t.
>
> Signed-off-by: Jarno Rajahalme
> ---
> lib/ofp-print.c|2 +-
> ofproto/ofproto-
Pushed to master,
Jarno
On Mar 24, 2014, at 10:14 AM, Ben Pfaff wrote:
> Looks good, thank you.
>
> On Mar 24, 2014 10:12 AM, "Jarno Rajahalme" wrote:
> 'metadata_match' and 'metadata_write' fields are defined as ovs_be64,
> but sometimes used and referred to as uint64_t.
>
> Signed-off-by
On Fri, Feb 21, 2014 at 11:41 AM, Jarno Rajahalme wrote:
> Minimize padding in sw_flow_key and move 'tp' top the main struct.
> These changes simplify code when accessing the transport port numbers
> and the tcp flags, and makes the sw_flow_key 8 bytes smaller on 64-bit
> systems (128->120 bytes).
Pushed to master,
Some comments below,
Jarno
On Mar 24, 2014, at 10:26 AM, Pravin Shelar wrote:
> On Fri, Feb 21, 2014 at 11:41 AM, Jarno Rajahalme
> wrote:
>> Minimize padding in sw_flow_key and move 'tp' top the main struct.
>> These changes simplify code when accessing the transport por
Inline the most trivial ofpbuf functions to allow for better optimization.
Also inline the most often used ofpbuf_pull() and ofpbuf_try_pull(), which
should help streamline packet parsing.
Signed-off-by: Jarno Rajahalme
---
lib/ofpbuf.c | 107
Using ofpbuf_end() to compute payload length would fail if the ofpbuf
had any tailroom.
Signed-off-by: Jarno Rajahalme
---
lib/pcap-file.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/pcap-file.c b/lib/pcap-file.c
index 2d3f9fe..e2fd203 100644
--- a/lib/pcap-file.c
Now that we don't need to parse TCP flags from the packet after
extraction, we usually do not need the 'l7' pointer any more. When
needed, ofpbuf_get_tcp|udp|sctp|icmp_payload() or ofpbuf_get_l4_size()
can be used instead.
Removal of 'l7' was requested by Pravin for the DPDK datapath work, as
it
Pravin,
I’ll need to send a new version of the rest of the patches due to this change.
You may want to hold your review for a while.
Jarno
On Mar 24, 2014, at 9:53 AM, Pravin Shelar wrote:
> On Mon, Mar 24, 2014 at 9:50 AM, Jarno Rajahalme
> wrote:
>>
>> On Mar 21, 2014, at 1:52 PM, Prav
Use netlink_has_listeners() and NLM_F_ECHO flag to determine if a
reply is needed or not for OVS_FLOW_CMD_NEW, OVS_FLOW_CMD_SET, or
OVS_FLOW_CMD_DEL.
Note: This may need compat support for older kernels.
Signed-off-by: Jarno Rajahalme
---
datapath/datapath.c | 57 +
Flow SET can accept an empty set of actions, with the intended
semantics of leaving existing actions unmodified. This seems to have
been brokin after OVS 1.7, as we have assigned the flow's actions
pointer to NULL in this case, but we never check for the NULL pointer
later on. This patch restores
Following patch will be easier to reason about with separate
ovs_flow_cmd_new() and ovs_flow_cmd_set() functions.
Signed-off-by: Jarno Rajahalme
---
datapath/datapath.c | 168 ---
1 file changed, 118 insertions(+), 50 deletions(-)
diff --git a/da
ovs_flow_cmd_del() now allocates reply (if needed) after the flow has
already been removed from the flow table. If the reply allocation
fails, a netlink error is signaled with netlink_set_err(), as is
already done in ovs_flow_cmd_new_or_set() in the similar situation.
Signed-off-by: Jarno Rajahal
Move most memory allocations away from the ovs_mutex critical
sections. vport allocations still happen while the lock is taken, as
changing that would require major refactoring. Also, vports are
created very rarely so it should not matter.
Change ovs_dp_cmd_get() now only takes the rcu_read_lock(
Remove unnecessary locking from functions that are always called with
appropriate locking.
Signed-off-by: Jarno Rajahalme
---
datapath/datapath.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/datapath/datapath.c b/datapath/datapath.c
index 918a990..7ce3ea6 1
Note that this has only a little performance benefit when responses
are not created (which is normal when there are no netlink multicast
listeners around).
Signed-off-by: Jarno Rajahalme
---
datapath/datapath.c | 127 ---
1 file changed, 71 insert
On Mon, Mar 24, 2014 at 11:56 AM, Jarno Rajahalme wrote:
> Flow SET can accept an empty set of actions, with the intended
> semantics of leaving existing actions unmodified. This seems to have
> been brokin after OVS 1.7, as we have assigned the flow's actions
> pointer to NULL in this case, but
Junguk Cho wrote:
I used ovs 2.0. So, I think it is 1.5 secs.
Can I adjust timeout values in command line tools?
Starting in OVS 2.2, there will be a configuration parameter to set the
default value. However, this knob is not really intended to be used by
users and will probably get removed
On Mar 24, 2014, at 12:24 PM, Pravin Shelar wrote:
> On Mon, Mar 24, 2014 at 11:56 AM, Jarno Rajahalme
> wrote:
>> Flow SET can accept an empty set of actions, with the intended
>> semantics of leaving existing actions unmodified. This seems to have
>> been brokin after OVS 1.7, as we have as
Since you are fixing locking, can you also fix flow-stats access in
ovs_flow_stats_get(). The access is always under ovs-mutex.
On Mon, Mar 24, 2014 at 11:56 AM, Jarno Rajahalme wrote:
> Remove unnecessary locking from functions that are always called with
> appropriate locking.
>
> Signed-off-by
On Mon, Mar 24, 2014 at 1:24 PM, Jarno Rajahalme wrote:
>
> On Mar 24, 2014, at 12:24 PM, Pravin Shelar wrote:
>
> On Mon, Mar 24, 2014 at 11:56 AM, Jarno Rajahalme
> wrote:
>
> Flow SET can accept an empty set of actions, with the intended
> semantics of leaving existing actions unmodified. Th
On Mon, Mar 24, 2014 at 10:59:03AM -0700, Jarno Rajahalme wrote:
> Using ofpbuf_end() to compute payload length would fail if the ofpbuf
> had any tailroom.
>
> Signed-off-by: Jarno Rajahalme
I guess this needs a backport?
Acked-by: Ben Pfaff
Thanks,
Ben.
This fixes four warnings of the following form on i386 and other 32-bit
architectures:
warning: format '%ld' expects argument of type 'long int', but
argument 2 has type 'unsigned int' [-Wformat]
Signed-off-by: Ben Pfaff
---
Makefile.am |2 +-
datapath/datapath.c |4 ++--
On Mon, Mar 24, 2014 at 10:59:04AM -0700, Jarno Rajahalme wrote:
> Inline the most trivial ofpbuf functions to allow for better optimization.
> Also inline the most often used ofpbuf_pull() and ofpbuf_try_pull(), which
> should help streamline packet parsing.
>
> Signed-off-by: Jarno Rajahalme
F
Starting in OVS 2.2, there will be a configuration parameter to set the
default value. However, this knob is not really intended to be used by
users and will probably get removed when we get more experience choosing a
good value. *Why the concern? * This should really be an implementation
detail
Jarno mentioned that this is debugging msg will be removed. So we can
just drop itfrom master.
On Mon, Mar 24, 2014 at 1:54 PM, Ben Pfaff wrote:
> This fixes four warnings of the following form on i386 and other 32-bit
> architectures:
>
> warning: format '%ld' expects argument of type 'long
On Mon, Mar 24, 2014 at 11:56 AM, Jarno Rajahalme wrote:
> Use netlink_has_listeners() and NLM_F_ECHO flag to determine if a
> reply is needed or not for OVS_FLOW_CMD_NEW, OVS_FLOW_CMD_SET, or
> OVS_FLOW_CMD_DEL.
>
> Note: This may need compat support for older kernels.
>
> Signed-off-by: Jarno Ra
On Mon, Mar 24, 2014 at 10:59:05AM -0700, Jarno Rajahalme wrote:
> Now that we don't need to parse TCP flags from the packet after
> extraction, we usually do not need the 'l7' pointer any more. When
> needed, ofpbuf_get_tcp|udp|sctp|icmp_payload() or ofpbuf_get_l4_size()
> can be used instead.
>
On Mon, Mar 24, 2014 at 11:56 AM, Jarno Rajahalme wrote:
> ovs_flow_cmd_del() now allocates reply (if needed) after the flow has
> already been removed from the flow table. If the reply allocation
> fails, a netlink error is signaled with netlink_set_err(), as is
> already done in ovs_flow_cmd_ne
On Mon, Mar 24, 2014 at 2:21 PM, Ben Pfaff wrote:
> On Mon, Mar 24, 2014 at 10:59:05AM -0700, Jarno Rajahalme wrote:
>> Now that we don't need to parse TCP flags from the packet after
>> extraction, we usually do not need the 'l7' pointer any more. When
>> needed, ofpbuf_get_tcp|udp|sctp|icmp_pay
Junguk Cho wrote:
Starting in OVS 2.2, there will be a configuration parameter to set the
default value. However, this knob is not really intended to be used by
users and will probably get removed when we get more experience choosing
a good value. *Why the concern? * This should really be an
i
On Mon, Mar 24, 2014 at 02:53:44PM -0700, Pravin Shelar wrote:
> On Mon, Mar 24, 2014 at 2:21 PM, Ben Pfaff wrote:
> > On Mon, Mar 24, 2014 at 10:59:05AM -0700, Jarno Rajahalme wrote:
> >> Now that we don't need to parse TCP flags from the packet after
> >> extraction, we usually do not need the '
On Mar 24, 2014, at 1:30 PM, Pravin Shelar wrote:
> Since you are fixing locking, can you also fix flow-stats access in
> ovs_flow_stats_get(). The access is always under ovs-mutex.
>
You mean adding a comment to that effect on top of ovs_flow_stats_get() in
datapath/flow.c?
How about the pat
Right,
I forgot about it, I’ll push a patch that removes it.
Sorry for the confusion,
Jarno
On Mar 24, 2014, at 2:07 PM, Pravin Shelar wrote:
> Jarno mentioned that this is debugging msg will be removed. So we can
> just drop itfrom master.
>
> On Mon, Mar 24, 2014 at 1:54 PM, Ben Pfaff w
Thanks!
On Mon, Mar 24, 2014 at 03:38:03PM -0700, Jarno Rajahalme wrote:
> Right,
>
> I forgot about it, I?ll push a patch that removes it.
>
> Sorry for the confusion,
>
> Jarno
>
> On Mar 24, 2014, at 2:07 PM, Pravin Shelar wrote:
>
> > Jarno mentioned that this is debugging msg will be
First part of the hash was discarded as basis was used too late.
Also be explicit about the input type expected by mhash_add().
Signed-off-by: Jarno Rajahalme
---
lib/flow.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/flow.c b/lib/flow.c
index 00e66a4..ac8
On Mon, Mar 24, 2014 at 10:59:05AM -0700, Jarno Rajahalme wrote:
> Now that we don't need to parse TCP flags from the packet after
> extraction, we usually do not need the 'l7' pointer any more. When
> needed, ofpbuf_get_tcp|udp|sctp|icmp_payload() or ofpbuf_get_l4_size()
> can be used instead.
>
Thx Jarno,
Looks good and tested with spare, and clang.
Acked-by: Alex Wang
On Mon, Mar 24, 2014 at 3:42 PM, Jarno Rajahalme wrote:
> First part of the hash was discarded as basis was used too late.
>
> Also be explicit about the input type expected by mhash_add().
>
> Signed-off-by: Jarno Ra
Thanks for the review!
Pushed to master,
Jarno
On Mar 24, 2014, at 3:46 PM, Alex Wang wrote:
> Thx Jarno,
>
> Looks good and tested with spare, and clang.
>
> Acked-by: Alex Wang
>
>
> On Mon, Mar 24, 2014 at 3:42 PM, Jarno Rajahalme
> wrote:
> First part of the hash was discarded as
Pushed to master,
Jarno
On Mar 24, 2014, at 1:41 PM, Pravin Shelar wrote:
> On Mon, Mar 24, 2014 at 1:24 PM, Jarno Rajahalme
> wrote:
>>
>> On Mar 24, 2014, at 12:24 PM, Pravin Shelar wrote:
>>
>> On Mon, Mar 24, 2014 at 11:56 AM, Jarno Rajahalme
>> wrote:
>>
>> Flow SET can accept an
I just pushed the patch that removes the offending pr_info from datapath,
Jarno
On Mar 24, 2014, at 3:33 PM, Ben Pfaff wrote:
> Thanks!
>
> On Mon, Mar 24, 2014 at 03:38:03PM -0700, Jarno Rajahalme wrote:
>> Right,
>>
>> I forgot about it, I?ll push a patch that removes it.
>>
>> Sorry for
This is the first patch series to add megaflow support for bond interface
using recirculation.
The final goal is that the bonding port selection will be made within the
datapath, using recirculation. Currently, the bonding port selection is
made in the user space, preventing possible wider mega f
Add basic recirculation infrastructure and user space
data path support for it. The following bond mega flow patch will
make use of this infrastructure.
Signed-off-by: Andy Zhou
---
v1->v2: Rewritten based on having post recirculation rules stored
in table 254.
V2->V3: Force recirc_i
Signed-off-by: Andy Zhou
---
v1 -> v2: Minor adjustment.
v2 -> v3: In comments, discouraging controllers to use newly added
recirc_id and dp_hash fields.
Reject openflow messages that references recirc_id and
dp_hash fields.
V3 -> v4: Rebase.
---
include/openf
Recirculation ID needs to be unique per datapath. Its usage will be
tracked by the backer that corresponds to the datapath.
In theory, Recirculation ID can be any uint32_t value, except 0. This
implementation limits to a smaller range just for ease of debugging.
Make the range size 0 effectively d
Please ignore this series. I have sent out v4 with some bug fixes.
Also re-based to the latest master.
On Fri, Mar 21, 2014 at 7:48 PM, Andy Zhou wrote:
> This is the first patch series to add megaflow support for bond interface
> using recirculation.
>
> The final goal is that the bonding port s
Thanks guys for reviews.
I pushed patch series to master.
On Fri, Mar 21, 2014 at 11:02 AM, Pravin wrote:
> Following patch adds DPDK netdev-class to userspace datapath.
> Approach taken in this patch differs from Intel DPDK vSwitch
> where DPDK datapath switching is done in saparate process. Th
Building OVS tree without DPDK produced the following warning message.
lib/dpif-netdev.c:1868:5: error: statement with no effect
This error message is complaining the return value of the following
macro, (0), is not being used.
#define pmd_thread_setaffinity_cpu(c) (0)
The patch fixe
On Mon, Mar 24, 2014 at 9:23 PM, Andy Zhou wrote:
> Building OVS tree without DPDK produced the following warning message.
> lib/dpif-netdev.c:1868:5: error: statement with no effect
>
> This error message is complaining the return value of the following
> macro, (0), is not being used.
>
Thanks Pravin, I will push it soon so that other people won't run into
build issues.
I agree with you that do / while will also work for void function
types. It is shorter than inline although inline provides argument
type checking.
Would do{} while (0) work for none void functions? What happens
I'd rather go with inline here because it will not warn about unused
variables, whereas I expect that "do {} while (0)" will in at least some
cases.
On Mon, Mar 24, 2014 at 10:51:11PM -0700, Andy Zhou wrote:
> Thanks Pravin, I will push it soon so that other people won't run into
> build issues.
>
Thanks, pushed.
On Mon, Mar 24, 2014 at 10:53 PM, Ben Pfaff wrote:
> I'd rather go with inline here because it will not warn about unused
> variables, whereas I expect that "do {} while (0)" will in at least some
> cases.
>
> On Mon, Mar 24, 2014 at 10:51:11PM -0700, Andy Zhou wrote:
>> Thanks Pr
63 matches
Mail list logo
