Hi,
I am sorry for the late response. I am working on the implementation of B. 19.
13-Meter action (EXT-379) of OF 1.5.1 to openvswitch.
The linux kernel meter implementation should likely use "Traffic Control"
module of linux. To implement meters we can create a mapping between the meter
The original message was included as attachment
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
This message was not delivered due to the following reason:
Your message could not be delivered because the destination server was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely the
Thanks Ben!
The last question is not valid if the answer to first question is Yes.
Thanks,
Faseela
-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Friday, June 10, 2016 8:55 AM
To: Faseela K
Cc: ovs dev
Subject: Re: [ovs-dev] Doubt regarding packet registers
On Thu, Jun 0
On Wed, Jun 8, 2016 at 11:49 PM, Aaron Conole wrote:
> Add ovs-tcpdump to the debian build.
>
> Signed-off-by: Aaron Conole
> ---
> * Introduced
>
> debian/openvswitch-switch.install | 1 +
> debian/openvswitch-switch.manpages | 1 +
> 2 files changed, 2 insertions(+)
>
>
Acked-by: Christian E
>> I understand that's what userspace does. What about in the datapath?
>> Do the datapaths properly handle it if userspace adds a flow that does
>> "truncate, pop_vlan, ..., output"? The kernel datapath, in particular,
>> should be able to handle malicious or buggy userspace.
>>
>
> There is che
Hi Ben,
Because for sFlow, it doesn't have any benefit to do
"sample(truncate(n), userspace(...))" in userspace datapath. I tried
to implement it by truncating the packet at OVS_ACTION_ATTR_USERSPACE
in dp_execute_cb() but it looks weird. And currently I couldn't think
of any other use case so I l
On Wed, Jun 8, 2016 at 11:21 AM, Thadeu Lima de Souza Cascardo
wrote:
> This series adds support for the creation of tunnels using the rtnetlink
> interface. This will open the possibility for new features and flags on those
> vports without the need to change vport compatibility code.
>
> Support
On Thu, Jun 9, 2016 at 7:38 PM, Ben Pfaff wrote:
> On Thu, Jun 09, 2016 at 05:32:05PM -0700, William Tu wrote:
>> >> Signed-off-by: William Tu
>> >
>> > I'm a bit nervous about cutlen. Can a packet change, for example by
>> > popping a VLAN header, after cutlen is set? If so, can this cause the
That was a fast revision! Thank you.
Even the new version fails for me, with the same difference: 10 packets
instead of 12. Do you have any ideas? The only unusual thing about my
system is that I use 32-bit x86 instead of 64-bit x86-64.
I'm appending a further incremental diff I suggest foldin
On Thu, Jun 09, 2016 at 09:15:26PM -0400, Russell Bryant wrote:
> On Thu, Jun 9, 2016 at 6:17 PM, Ben Pfaff wrote:
>
> > Signed-off-by: Ben Pfaff
> >
>
> Acked-by: Russell Bryant
Thanks, applied.
___
dev mailing list
dev@openvswitch.org
http://openv
On Thu, Jun 09, 2016 at 11:38:46PM +, Faseela K wrote:
>I would like to know the difference in behavior between metadata field and
> packet register.
>Is register a per-packet entity like metadata field?
Yes.
> If there is an action to copy metadata value to a packet register,
> will
On Fri, Jun 10, 2016 at 3:34 AM, FlaviofOvsML wrote:
>
>
> On Tue, Jun 7, 2016 at 1:49 AM, Numan Siddique
> wrote:
>
>> OVN implements a native DHCP support which caters to the common
>> use case of providing an IP address to a booting instance by
>> providing stateless replies to DHCP requests
On Thu, Jun 09, 2016 at 06:06:47PM -0700, William Tu wrote:
> > I'm not sure why CHECK_TRUNC_USERSPACE exists, because I think that your
> > patch implements the new action in userspace.
>
> When translating sflow header config, only if it runs kernel datapath,
> I will program truncate to sample'
On 9 June 2016 at 08:50, Terry Wilson wrote:
> On Thu, Jun 9, 2016 at 3:07 AM, Russell Bryant wrote:
>> The real solution to making this less awkward would be to split the Python
>> library out of the OVS git tree so that it can be released independently of
>> OVS itself. That way a proper veris
On Thu, Jun 09, 2016 at 05:32:05PM -0700, William Tu wrote:
> >> Signed-off-by: William Tu
> >
> > I'm a bit nervous about cutlen. Can a packet change, for example by
> > popping a VLAN header, after cutlen is set? If so, can this cause the
> > packet length to drop below 0, or below 14?
> >
>
It is meaningful for user to check the stats of IPFIX.
Using IPFIX stats, user can know how much flows the system
can support. It is also can be used for performance check
of IPFIX.
IPFIX stats is added for per IPFIX exporter. If bridge IPFIX is
enabled on the bridge, the whole bridge will have on
Hi Ben,
Thanks for your review. For the test case, I didn’t get an error in my test
machine. I suspected that IPFIX packets are
not all sent before dump IPFIX stats, so 'sleep 1' is added to make sure all
the IPFIX packets are sent.
Bests,
Daniel Benli Ye
> On Jun 10, 2016, at 5:33 AM, Ben Pfa
On Thu, Jun 9, 2016 at 11:50 AM, Terry Wilson wrote:
> On Thu, Jun 9, 2016 at 3:07 AM, Russell Bryant wrote:
> > The real solution to making this less awkward would be to split the
> Python
> > library out of the OVS git tree so that it can be released independently
> of
> > OVS itself. That wa
Hi Ryan,
Thanks for the review. I looked at the jsonrpc-server.c and I think
it's OK without leaks.
Regards,
William
On Wed, Jun 8, 2016 at 7:32 PM, Ryan Moats wrote:
> "dev" wrote on 06/05/2016 09:37:35 AM:
>
>> From: William Tu
>> To: dev@openvswitch.org
>> Date: 06/05/2016 09:37 AM
>> Subj
On Thu, Jun 9, 2016 at 6:17 PM, Ben Pfaff wrote:
> Signed-off-by: Ben Pfaff
>
Acked-by: Russell Bryant
--
Russell Bryant
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Hi Ben,
Thanks for the review.
> This changes the "wire format" of the NXAST_SAMPLE action, but we can't
> do that because it will break compatibility with older OpenFlow clients.
> Usually if we need a new feature in an action we add a new version that
> has that feature, e.g. NXAST_SAMPLE2. The
Hello!
We are looking for employees working remotely.
My name is Bette, am the personnel manager of a large International company.
Most of the work you can do from home, that is, at a distance.
Salary is $2500-$5000.
If you are interested in this offer, please visit
Our Site
Best regards!
When calling odp_flow_key_from_flow (or _mask), the in_port included
as part of the flow is ignored and must be explicitly passed as a
separate parameter. This is because the assumption was that the flow's
version would often be in OFP format, rather than ODP.
However, at this point all flows that
When debug logging is enabled, dpif-netdev can print each flow as it is
installed, which it currently does using OpenFlow match formatting. Compared
to ODP formatting, there generally isn't too much difference since the
fields are largely the same but it is inconsistent with other logging in
dpif-n
When we generate wildcards for upcalled flows, the flows and therefore
the wildcards, are in OpenFlow format. These are mostly the same but
one exception is the input port. We work around this problem by simply
performing an exact match on the input port when generating netlink
formatted keys. (Thi
Hi Ben,
Thanks for the feedback.
>> Signed-off-by: William Tu
>
> I'm a bit nervous about cutlen. Can a packet change, for example by
> popping a VLAN header, after cutlen is set? If so, can this cause the
> packet length to drop below 0, or below 14?
>
I don't want this happen. As a result,
On Tue, Jun 07, 2016 at 10:53:54PM -0700, William Tu wrote:
> This patch adds a 'snaplen' config for mirroring table. A mirrored packet
> with size larger than snaplen bytes will be truncated in datapath before
> sending to the mirror output port. A snaplen of 0 equals 65535, which means
> no tru
On Thu, Jun 09, 2016 at 12:12:37AM -0700, Justin Pettit wrote:
> A few minor changes related to logical router port commands:
>
> - Use "lrp" instead of "lrport" to be more consistent with later
> changes.
> - Use commands where possible in ovn unit tests.
> - Move documentation
> On Jun 9, 2016, at 16:24, Ben Pfaff wrote:
>
>> On Thu, Jun 09, 2016 at 03:45:25PM -0700, Jarno Rajahalme wrote:
>> OVS_FIND_PARAM_IFELSE is more robust macro for checking function
>> parameters, as it does not require the parameter to be on the same
>> line as the function name like the OVS_G
On Tue, Jun 07, 2016 at 10:53:53PM -0700, William Tu wrote:
> This patch adds a 'snaplen' field in sample action. Currently, sample
> action is used by sFlow and IPFIX. For IPFIX, nothing is changed. For
> sFlow configuration, the patch translates header=N to a sample action with
> snaplen=N, the
On Tue, Jun 07, 2016 at 10:53:52PM -0700, William Tu wrote:
> The patch adds a new action to support packet truncation. The new action
> is formatted as 'output(port=n,max_len=m)', as output to port n, with
> packet size being MIN(original_size, m).
>
> One use case is to enable port mirroring to
> On Jun 9, 2016, at 9:57 AM, Darrell Ball wrote:
>
> I edited the error msgs, per below, in the previous response with an upper
> range change; that was my suggestion.
>
> + return xasprintf("%s: IPv4 network prefix bits not between 0 and "
> +"32, inclusi
Are you tired of the excess weight and would like to get back on track without
any painful efforts?
Brand-new formula and advanced structure of our exclusive product will
compliment your results
and will help you to lose weight with no side-effects.
Click Here!
Stock is limited, make sure to
Hi,
I would like to know the difference in behavior between metadata field and
packet register.
Is register a per-packet entity like metadata field?
If there is an action to copy metadata value to a packet register, will
there be any performance impact on the packet processing pipeline,
From: Nirapada Ghosh
This change is just a minor cleanup to remove VLOG_WARN
from ovn-nbctl.c and use ctl_fatal. I believe, VLOG_WARN
is not supposed to be used here.
---
ovn/utilities/ovn-nbctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ovn/utilities/ovn-nbctl.c
This change is just a minor cleanup to remove VLOG_WARN
from ovn-nbctl.c and use ctl_fatal. I believe, VLOG_WARN
is not supposed to be used here.
Signed-off-by: Nirapada Ghosh
---
ovn/utilities/ovn-nbctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ovn/utilities/ovn
This change is just a minor cleanup to remove VLOG_WARN
from ovn-nbctl.c and use ctl_fatal. I believe, VLOG_WARN
is not supposed to be used here.
Signed-off-by: Nirapada Ghosh
---
ovn/utilities/ovn-nbctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ovn/utilities/ovn
This change is just a minor cleanup to remove VLOG_WARN
from ovn-nbctl.c and use ctl_fatal. I believe, VLOG_WARN
is not supposed to be used here.
Signed-off-by: Nirapada Ghosh
---
ovn/utilities/ovn-nbctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ovn/utilities/ovn
On Thu, Jun 09, 2016 at 03:45:25PM -0700, Jarno Rajahalme wrote:
> OVS_FIND_PARAM_IFELSE is more robust macro for checking function
> parameters, as it does not require the parameter to be on the same
> line as the function name like the OVS_GREP_IFELSE does.
>
> Use this to fix the check for stru
NF_CT_NEW_REPLY definition has been removed upstream as it did not
make sense (NEW can never be a REPLY).
Signed-off-by: Jarno Rajahalme
---
datapath/conntrack.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/datapath/conntrack.c b/datapath/conntrack.c
index 13cacf4..4b6fdae 100644
--- a/d
Extend OVS conntrack interface to cover NAT. New nested
OVS_CT_ATTR_NAT attribute may be used to include NAT with a CT action.
A bare OVS_CT_ATTR_NAT only mangles existing and expected connections.
If OVS_NAT_ATTR_SRC or OVS_NAT_ATTR_DST is included within the nested
attributes, new (non-committed
Compat code required to make the NAT code in the following patch
compile with Linux 3.10 - 4.3.
Signed-off-by: Jarno Rajahalme
---
acinclude.m4 | 3 +
datapath/linux/Modules.mk | 4 +
.../linux/compat/include/linux/netfilter/nf_nat
Older kernels don't have , which causes
compilation to fail on GCC 5.
Signed-off-by: Jarno Rajahalme
---
acinclude.m4 | 4 ++
datapath/linux/Modules.mk | 1 +
.../linux/compat/include/linux/compiler-gcc5.h | 71
OVS_FIND_PARAM_IFELSE is more robust macro for checking function
parameters, as it does not require the parameter to be on the same
line as the function name like the OVS_GREP_IFELSE does.
Use this to fix the check for struct conntrack_zone parameter, which
is on a different line on Linux 4.3 and
Repeat the nf_conntrack_in() call when it returns NF_REPEAT. This
avoids dropping a SYN packet re-opening an existing TCP connection.
Signed-off-by: Jarno Rajahalme
Acked-by: Joe Stringer
---
datapath/conntrack.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/da
There is no need to help connections that are not confirmed, so we can
delay helping new connections to the time when they are confirmed.
This change is needed for NAT support, and having this as a separate
patch will make the following NAT patch a bit easier to review.
This patch also squashes in
This makes the code easier to understand and the following patches
more focused.
Signed-off-by: Jarno Rajahalme
Acked-by: Joe Stringer
---
datapath/conntrack.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/datapath/conntrack.c b/datapath/conntrack.c
i
Add a new function ovs_ct_find_existing() to find an existing
conntrack entry for which this packet was already applied to. This is
only to be called when there is evidence that the packet was already
tracked and committed, but we lost the ct reference due to an
userspace upcall.
ovs_ct_find_exis
Only a successful nf_conntrack_in() call can effect a connection state
change, so it suffices to update the key only after the
nf_conntrack_in() returns.
This change is needed for the later NAT patches.
Signed-off-by: Jarno Rajahalme
Acked-by: Joe Stringer
---
datapath/conntrack.c | 7 ---
This series adds the conntrack NAT integration upstreamed in Linux 4.6
to the OVS tree kernel module. Main code is the same as upstream,
backports are provided for Linux kernels 3.10 - 4.3. Code compiles on
the latest release of each Linux version on this range. Linux 4.4 and
4.5 remain untested
On Tue, Jun 07, 2016 at 07:05:38PM -0700, Justin Pettit wrote:
> Signed-off-by: Justin Pettit
Acked-by: Ben Pfaff
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Hi Ben,
Regarding https://patchwork.ozlabs.org/patch/630046/ :
I see that this patch is marked "changes requested" in patchwork. I
believe this is due to Alin's request (below).
I'm having trouble understanding how the offending line is finding
its way into ovsdb-server-log; I've attempted to re
On Thu, Jun 09, 2016 at 12:12:42AM -0700, Justin Pettit wrote:
> A few minor changes related to logical switch commands:
>
> - Use "ls" instead of "lswitch" to be more consistent with other
> command changes.
> - Use commands where possible in ovn unit tests.
>
On Thu, Jun 09, 2016 at 12:12:41AM -0700, Justin Pettit wrote:
> A few minor changes related to logical switch port commands:
>
> - Use "lsp" instead of "lport" to be more consistent with later
> changes.
> - Use commands where possible in ovn unit tests.
> - Update references fr
On Thu, Jun 09, 2016 at 12:12:40AM -0700, Justin Pettit wrote:
> We have both logical switch and router ports. Router ports are
> referenced in "Logical_Router_Port" table, so this make it more
> consistent.
>
> Also change internal use of "lport" to "lsp".
>
> Signed-off-by: Justin Pettit
Nam
There is no particularly good reason to use our own Python JSON
serialization implementation when serialization can be done faster
with Python's built-in JSON library.
A few tests were changed due to Python's default JSON library
returning slightly more precise floating point numbers.
Signed-off-
On Thu, Jun 09, 2016 at 12:12:39AM -0700, Justin Pettit wrote:
> Signed-off-by: Justin Pettit
I think the documentation can be improved. Suggested incremental
appended.
It's not actually necessary to call
nbrec_logical_router_verify_static_routes() when deleting all routes,
because the result o
Signed-off-by: Ben Pfaff
---
ovn/ovn-nb.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
index 41092f1..130b63b 100644
--- a/ovn/ovn-nb.xml
+++ b/ovn/ovn-nb.xml
@@ -757,7 +757,7 @@
-The name of the via which the packe
On Tue, Jun 7, 2016 at 1:49 AM, Numan Siddique wrote:
> OVN implements a native DHCP support which caters to the common
> use case of providing an IP address to a booting instance by
> providing stateless replies to DHCP requests based on statically
> configured address mappings. To do this it al
On Thu, Jun 09, 2016 at 12:12:38AM -0700, Justin Pettit wrote:
> A zero prefix length is used to match any IP address, which is useful
> for defining default routes.
>
> Signed-off-by: Justin Pettit
With Darrell's comments,
Acked-by: Ben Pfaff
___
dev
On Thu, Jun 09, 2016 at 12:12:36AM -0700, Justin Pettit wrote:
> A few minor changes related to router commands:
>
> - Use "lr" instead of "lrouter" to be more consistent with later
> changes.
> - Use the commands where possible in ovn unit tests.
> - Move documentation to group
On Thu, Jun 09, 2016 at 12:12:35AM -0700, Justin Pettit wrote:
> Signed-off-by: Justin Pettit
Acked-by: Ben Pfaff
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Wed, Jun 08, 2016 at 06:45:25PM +0800, Benli Ye wrote:
> It is meaningful for user to check the stats of IPFIX.
> Using IPFIX stats, user can know how much flows the system
> can support. It is also can be used for performance check
> of IPFIX.
Thanks for posting v3!
I think that this is close
In some circumstances, we might need to figure out where in
code, the CPU time is being spent most, so as to pinpoint
the bottleneck and thereby resolve it with proper changes.
Using '-finstrument-functions' flag, that can be achieved, and
this patch exactly does that.
There is a python file [gene
On Wed, Jun 08, 2016 at 07:13:38PM +0800, Benli Ye wrote:
> Add support to export tunnel information for flow-based IPFIX.
> The original steps to configure flow level IPFIX:
> 1) Create a new record in Flow_Sample_Collector_Set table:
>'ovs-vsctl -- create Flow_Sample_Collector_Set id=
On 09.06.2016 22:35, Alexander Duyck wrote:
> On Thu, Jun 9, 2016 at 12:23 PM, Hannes Frederic Sowa
> wrote:
>> On 09.06.2016 18:14, Alexander Duyck wrote:
>>> On Thu, Jun 9, 2016 at 3:57 AM, Hannes Frederic Sowa
>>> wrote:
On 09.06.2016 04:33, Alexander Duyck wrote:
> On Wed, Jun 8, 2
On Thu, Jun 9, 2016 at 4:55 PM, Ben Pfaff wrote:
> On Thu, Jun 09, 2016 at 09:22:10PM +0100, Russell Bryant wrote:
> > A previous commit added this file to be checked by flake8, but the file
> > failed a number of checks done by the 'hacking' flake8 plugin.
> >
> > Fixes: b00bdc728e7a ("automake:
On Thu, Jun 09, 2016 at 09:22:10PM +0100, Russell Bryant wrote:
> A previous commit added this file to be checked by flake8, but the file
> failed a number of checks done by the 'hacking' flake8 plugin.
>
> Fixes: b00bdc728e7a ("automake: Add ovs-bugtool.in to flake8-check.")
> Signed-off-by: Russ
On Thu, Jun 9, 2016 at 4:42 PM, Aaron Rosen wrote:
> The patch b00bdc728e7a0ae697b4fc59a4f9958b688c6789 enabled flake8-checking
> to be run on ovs-bugtool.in which failed due to python3 issues. This
> patch fixes those issues.
>
> Signed-off-by: Aaron Rosen
>
Thanks for the patch, Aaron. I act
The patch b00bdc728e7a0ae697b4fc59a4f9958b688c6789 enabled flake8-checking
to be run on ovs-bugtool.in which failed due to python3 issues. This
patch fixes those issues.
Signed-off-by: Aaron Rosen
---
utilities/bugtool/ovs-bugtool.in | 45 +---
1 file changed,
On 9 June 2016 at 13:27, Russell Bryant wrote:
> On Thu, Jun 9, 2016 at 4:20 PM, Guru Shetty wrote:
>
> > On 9 June 2016 at 13:14, Aaron Rosen wrote:
> >
> > > This patch seemed to break the build with some flake8 python3 errors
> for
> > > me. I have a patch coming up to fix it.
> > >
> >
> >
On Thu, Jun 9, 2016 at 4:35 PM, Kyle Mestery wrote:
> On Thu, Jun 9, 2016 at 3:22 PM, Russell Bryant wrote:
> > A previous commit added this file to be checked by flake8, but the file
> > failed a number of checks done by the 'hacking' flake8 plugin.
> >
> > Fixes: b00bdc728e7a ("automake: Add o
On 9 June 2016 at 13:22, Russell Bryant wrote:
> A previous commit added this file to be checked by flake8, but the file
> failed a number of checks done by the 'hacking' flake8 plugin.
>
> Fixes: b00bdc728e7a ("automake: Add ovs-bugtool.in to flake8-check.")
> Signed-off-by: Russell Bryant
>
On Thu, Jun 9, 2016 at 3:22 PM, Russell Bryant wrote:
> A previous commit added this file to be checked by flake8, but the file
> failed a number of checks done by the 'hacking' flake8 plugin.
>
> Fixes: b00bdc728e7a ("automake: Add ovs-bugtool.in to flake8-check.")
> Signed-off-by: Russell Bryant
On Thu, Jun 9, 2016 at 12:23 PM, Hannes Frederic Sowa wrote:
> On 09.06.2016 18:14, Alexander Duyck wrote:
>> On Thu, Jun 9, 2016 at 3:57 AM, Hannes Frederic Sowa
>> wrote:
>>> On 09.06.2016 04:33, Alexander Duyck wrote:
On Wed, Jun 8, 2016 at 3:20 PM, Hannes Frederic Sowa
wrote:
>>>
On Thu, Jun 9, 2016 at 4:20 PM, Guru Shetty wrote:
> On 9 June 2016 at 13:14, Aaron Rosen wrote:
>
> > This patch seemed to break the build with some flake8 python3 errors for
> > me. I have a patch coming up to fix it.
> >
>
>
Sorry, I posted a patch before seeing this.
http://openvswitch.org/
- Original Message -
> From: "Guru Shetty"
> To: "Aaron Rosen"
> Cc: "ovs dev"
> Sent: Thursday, June 9, 2016 4:20:37 PM
> Subject: Re: [ovs-dev] [PATCH 8/8] automake: Add ovs-bugtool.in to
> flake8-check.
>
> On 9 June 2016 at 13:14, Aaron Rosen wrote:
>
> > This patch seemed to
A previous commit added this file to be checked by flake8, but the file
failed a number of checks done by the 'hacking' flake8 plugin.
Fixes: b00bdc728e7a ("automake: Add ovs-bugtool.in to flake8-check.")
Signed-off-by: Russell Bryant
---
utilities/bugtool/ovs-bugtool.in | 48 +++
On 9 June 2016 at 13:14, Aaron Rosen wrote:
> This patch seemed to break the build with some flake8 python3 errors for
> me. I have a patch coming up to fix it.
>
Oink. Should I be doing more than a "pip install flake8" and make
flake8-check to trigger these problems?
>
> On Thu, Jun 9, 2016 a
This patch seemed to break the build with some flake8 python3 errors for
me. I have a patch coming up to fix it.
On Thu, Jun 9, 2016 at 11:06 AM, Guru Shetty wrote:
> >
> >
> >
> > All of these didn't appear to make the patchworks queue,
> > so the following is an ack of the whole series - I've
The probe timer between ovn-controller and OVN Southbound
can be configured using ovn-vsctl command, but that is not
effective on the fly. In other words, ovn-controller has
to be restarted to use that probe_timer value, this patch
takes care of that.
This change has been tested putting logs in se
On Thu, Jun 9, 2016 at 12:18 PM, Jesse Gross wrote:
> On Thu, Jun 9, 2016 at 12:03 PM, Pravin B Shelar wrote:
>> Upstream commit:
>> commit b4f70527f052b0c00be4d7cac562baa75b212df5
>> Author: Simon Horman
>> Date: Thu Apr 21 11:49:15 2016 +1000
>>
>> openvswitch: use flow proto
On 09.06.2016 18:14, Alexander Duyck wrote:
> On Thu, Jun 9, 2016 at 3:57 AM, Hannes Frederic Sowa
> wrote:
>> On 09.06.2016 04:33, Alexander Duyck wrote:
>>> On Wed, Jun 8, 2016 at 3:20 PM, Hannes Frederic Sowa
>>> wrote:
The remaining problem regarding offloads would be, that we by defau
On Thu, Jun 9, 2016 at 12:03 PM, Pravin B Shelar wrote:
> Upstream commit:
> commit b4f70527f052b0c00be4d7cac562baa75b212df5
> Author: Simon Horman
> Date: Thu Apr 21 11:49:15 2016 +1000
>
> openvswitch: use flow protocol when recalculating ipv6 checksums
>
> When using mask
Upstream commit:
commit b4f70527f052b0c00be4d7cac562baa75b212df5
Author: Simon Horman
Date: Thu Apr 21 11:49:15 2016 +1000
openvswitch: use flow protocol when recalculating ipv6 checksums
When using masked actions the ipv6_proto field of an action
to set IPv6 fields may
Since tunnel metadata is stored in a fixed area in the flow match field, we
must allocate space for options as they are registered with the switch. In order
to avoid exposing implementation complexity to the controller, we support
fragmentation when we run out of contiguous blocks that are large en
On Thu, Jun 9, 2016 at 7:31 AM, Ryan Moats wrote:
> From: RYAN D. MOATS
>
> We've been compiling and testing against the 4.6.0 kernel
> tree and 2.5.90 looks pretty good. So, let's start the
> update pieces.
>
> Signed-off-by: RYAN D. MOATS
There are a bunch of patches from 4.4-4.6 that aren't
In some circumstances, we might need to figure out where in
code, the CPU time is being spent most, so as to pinpoint
the bottleneck and thereby resolve it with proper changes.
Using '-finstrument-functions' flag, that can be achieved, and
this patch exactly does that.
There is a python file [gene
In some circumstances, we might need to figure out where in
code, the CPU time is being spent most, so as to pinpoint
the bottleneck and thereby resolve it with proper changes.
Using '-finstrument-functions' flag, that can be achieved, and
this patch exactly does that.
There is a python file [gene
>
>
>
> All of these didn't appear to make the patchworks queue,
> so the following is an ack of the whole series - I've
> looked at all of them and they look good...
>
> Acked-by: Ryan Moats
>
> Thank you Ryan! I applied the series.
___
dev mailing list
"dev" wrote on 06/09/2016 02:12:41 AM:
> From: Justin Pettit
> To: dev@openvswitch.org
> Date: 06/09/2016 02:14 AM
> Subject: [ovs-dev] [PATCH 7/8] ovn-nbctl: Update logical switch
portcommands.
> Sent by: "dev"
>
> A few minor changes related to logical switch port commands:
>
> - Use "lsp
For traffic from physical space to virtual space we need DNAT.
The DNAT happens in the gateway router and reaches the logical
port. The return traffic should be unDNATed.
Traffic originating in virtual space heading to physical space
should be SNATed. The return traffic is unSNATted.
East-west tr
Works for me.
Mickey
-Guru Shetty wrote: -
To: Mickey Spiegel/San Jose/IBM@IBMUS
From: Guru Shetty
Date: 06/09/2016 10:20AM
Cc: ovs dev
Subject: Re: [ovs-dev] [PATCH v3 5/5] ovn: DNAT and SNAT on a gateway router.
Thinking about "logical_ip" and "physical_ip", I am concerned that
"
On 2 June 2016 at 14:48, Ben Pfaff wrote:
> On Thu, May 19, 2016 at 01:02:34PM -0700, Gurucharan Shetty wrote:
> > For traffic from physical space to virtual space we need DNAT.
> > The DNAT happens in the gateway router and reaches the logical
> > port. The return traffic should be unDNATed.
> >
>
>
> Thinking about "logical_ip" and "physical_ip", I am concerned that
> "physical_ip" will confuse people. When I hear "physical_ip", my mind
> wanders to pieces of hardware, which is not what this is about.
>
> How about "internal_ip"/"external_ip"?
>
I decided to use "logical_ip"/"external_ip
On Thu, Jun 9, 2016 at 3:12 AM, Justin Pettit wrote:
> A zero prefix length is used to match any IP address, which is useful
> for defining default routes.
>
> Signed-off-by: Justin Pettit
>
Acked-by: Flavio Fernandes
> ---
> lib/packets.c | 10 +-
> 1 file changed, 5 insertions(+
On Thu, Jun 9, 2016 at 9:38 AM, Justin Pettit wrote:
>
> > On Jun 9, 2016, at 9:25 AM, Darrell Ball wrote:
> >
> >
> >
> > On Thu, Jun 9, 2016 at 12:12 AM, Justin Pettit wrote:
> > A zero prefix length is used to match any IP address, which is useful
> > for defining default routes.
> >
> > Sig
On Thu, Jun 9, 2016 at 1:14 AM, Jesse Gross wrote:
> On Wed, Jun 8, 2016 at 7:33 PM, Alexander Duyck
> wrote:
>> Agreed, but what are we really getting by adding the port value? In
>> the case of the Intel hardware it isn't much as I can take advantage
>> of checksum offload if I just turn on th
On Thu, Jun 9, 2016 at 11:07 AM, Ben Pfaff wrote:
> Patches 1 and 2 are new.
>
> Patch 3 is based on https://patchwork.ozlabs.org/patch/631320/, with:
> - Minor style fixes.
> - Change syntax of put_dhcp_opts(), from:
> put_dhcp_opts(reg0, offerip=1.2.3.4, ...)
> to:
> reg0[0]
1 - 100 of 133 matches
Mail list logo
