One more comment, if you will be working on v3.
On Thu, Apr 7, 2016 at 8:46 AM, Russell Bryant wrote:
> diff --git a/ovn/ovn-nb.ovsschema b/ovn/ovn-nb.ovsschema
> index 40a7a97..c26d8ae 100644
> --- a/ovn/ovn-nb.ovsschema
> +++ b/ovn/ovn-nb.ovsschema
> @@ -1,7 +1,7 @@
> {
> "name": "OVN_Nor
tch=(((ct.new && !ct.est)
> || (!ct.new && ct.est && !ct.rpl && ct_label[0] == 1)) && (outport ==
> "0a7409c8-d179-4915-9eb2-f53426ae16dd" && ip4 && icmp4)),
> action=(ct_commit(ct_label=0); next;)
> > table=1(
Signed-off-by: Han Zhou
---
ovn/utilities/ovn-nbctl.8.xml | 10 +-
ovn/utilities/ovn-nbctl.c | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/ovn/utilities/ovn-nbctl.8.xml b/ovn/utilities/ovn-nbctl.8.xml
index 122a114..74e79a3 100644
--- a/ovn/utilities/ovn
On Tue, Aug 9, 2016 at 8:55 PM, Zong Kai LI wrote:
>
> This patch renames table Address_Set to Set, Address_Set.addresses to
> Set.members to reflect a more broad purpose, that we can define other
types
> of sets than address set.
>
> Per discussion around [1] and [2], this patch only does rename
Make sense! Thanks for explain :)
On Wednesday, August 10, 2016, Zong Kai Li wrote:
> On Thu, Aug 11, 2016 at 1:51 PM, Han Zhou > wrote:
> >
> >
> > On Tue, Aug 9, 2016 at 8:55 PM, Zong Kai LI > wrote:
> >>
> >> This patch renames table
Signed-off-by: Han Zhou
---
FAQ.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/FAQ.md b/FAQ.md
index df6f225..cc4fdf6 100644
--- a/FAQ.md
+++ b/FAQ.md
@@ -1056,7 +1056,7 @@ A: Yes. For traffic that egresses from a switch, OVS
supports traffic
Keep in mind that
Sorry, I think I just realized that the "not" here is optional in English.
But it did take me sometime to figure out :(
Han
On Mon, Jun 6, 2016 at 10:56 PM, Han Zhou wrote:
> Signed-off-by: Han Zhou
> ---
> FAQ.md | 2 +-
> 1 file changed, 1 insertion(+), 1 deleti
Thanks Babu for taking over this. I'd like to repost my comment here:
On Wed, Jun 22, 2016 at 10:05 PM, wrote:
> diff --git a/ovn/ovn-sb.ovsschema b/ovn/ovn-sb.ovsschema
> index 06e8a07..22f7ad0 100644
> --- a/ovn/ovn-sb.ovsschema
> +++ b/ovn/ovn-sb.ovsschema
> @@ -1,7 +1,7 @@
> {
> "name"
On Sun, Jun 26, 2016 at 11:29 PM, Babu Shanmugam
wrote:
>
>
>
> On Thursday 23 June 2016 12:03 PM, Han Zhou wrote:
>>
>> It may be good to have column "external_ids", so that external names,
such as security-group name in neutron, can be recognized easily.
>
&
On Tue, Feb 23, 2016 at 1:04 PM, Ben Pfaff wrote:
>
> Will this have the desired effect? I think that putting multiple VIFs
> on a logical switch and redirecting outputs to them through the localnet
> port will have surprising consequences in some cases. The first case
> that comes to mind is on
lnet port configured on the lswitch.
Signed-off-by: Han Zhou
---
Notes:
v1->v2: rebase on master, and more updates on documents
v2->v3: updated based on Russell's comments
v3->v4: rebase on master, and updated ovn-nb.xml document
v4->v5: rebase and documents up
On Tue, Feb 23, 2016 at 3:38 PM, Han Zhou wrote:
>
>
> On Tue, Feb 23, 2016 at 1:04 PM, Ben Pfaff wrote:
> >
> > Will this have the desired effect? I think that putting multiple VIFs
> > on a logical switch and redirecting outputs to them through the localnet
&g
On Wed, Feb 24, 2016 at 4:26 AM, Russell Bryant wrote:
>
> On Wed, Feb 24, 2016 at 2:12 AM, Han Zhou wrote:
>>
>> Before this patch, inter-chassis communication between VIFs of same
>> lswitch will always go through tunnel, which end up of modeling a
>> sin
On Tue, Feb 23, 2016 at 11:27 PM, Han Zhou wrote:
>
>
>
> On Tue, Feb 23, 2016 at 3:38 PM, Han Zhou wrote:
>>
>>
>>
>> On Tue, Feb 23, 2016 at 1:04 PM, Ben Pfaff wrote:
>> >
>> > Will this have the desired effect? I think that putting
lnet port configured on the lswitch.
Signed-off-by: Han Zhou
Acked-by: Russell Bryant
---
Notes:
v1->v2: rebase on master, and more updates on documents
v2->v3: updated based on Russell's comments
v3->v4: rebase on master, and updated ovn-nb.xml document
v4-&g
On Thu, Feb 25, 2016 at 12:43 PM, Russell Bryant wrote:
>
>
>
> On Thu, Feb 25, 2016 at 1:12 PM, Han Zhou wrote:
>>
>> Before this patch, inter-chassis communication between VIFs of same
>> lswitch will always go through tunnel, which end up of modeling a
>&g
responder before
ls_in_l2_lkup.
Suggested-by: Russell Bryant
Signed-off-by: Han Zhou
---
ovn/northd/ovn-northd.8.xml | 27 +++
ovn/northd/ovn-northd.c | 40 +---
2 files changed, 56 insertions(+), 11 deletions(-)
diff --git a/ovn/northd
responder before
ls_in_l2_lkup.
Suggested-by: Russell Bryant
Signed-off-by: Han Zhou
---
ovn/northd/ovn-northd.8.xml | 27 +++
ovn/northd/ovn-northd.c | 40 +---
2 files changed, 56 insertions(+), 11 deletions(-)
diff --git a/ovn/northd
lnet port configured on the lswitch.
Signed-off-by: Han Zhou
Acked-by: Russell Bryant
---
Notes:
v1->v2: rebase on master, and more updates on documents
v2->v3: updated based on Russell's comments
v3->v4: rebase on master, and updated ovn-nb.xml document
v4-&g
When a lport is with address "unknown", the function will complain
and print misleading logs. There is no need to print the log.
---
ovn/northd/ovn-northd.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index b2b1a45..63f3fcd 100644
--- a/o
When a lport is with address "unknown", the function will complain
and print misleading logs. There is no need to print the log.
Signed-off-by: Han Zhou
---
ovn/northd/ovn-northd.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-nort
On Fri, Feb 26, 2016 at 7:59 AM, Russell Bryant wrote:
>
>
>
> On Thu, Feb 25, 2016 at 11:26 PM, Han Zhou wrote:
>>
>> This is required by next commit that allows lswitch with localnet
>> port to be attached to multiple chassises. Without this patch, if
>> an
On Wed, Mar 2, 2016 at 11:27 AM, Darrell Ball wrote:
>
> Thanks Russell
>
> Pls see inline
>
> Darrell
>
>
> From: Russell Bryant
> Date: Wednesday, March 2, 2016 at 5:40 AM
> To: Darrel Ball
> Cc: Mickey Spiegel , Darrell Lu , "
dev@openvswitch.org&q
On Wed, Mar 2, 2016 at 1:43 PM, Russell Bryant wrote:
>
> Update the "ct_commit;" logical flow action to optionally take a
> parameter, setting the value of "ct_mark" to a 32-bit integer.
> Supported ct_commit syntax now includes:
>
> ct_commit;
> ct_commit();
> ct_commit(ct_mark=1);
>
On Sun, Mar 6, 2016 at 11:02 PM, Lei Huang wrote:
>
> Hi,
>
>
> During a scalability test, we found that the ovn northbound ovsdb-server’s
> memory usage becomes very high while creating and binding ports, the test
> step is:
>
> 1. Create 1000 sandboxes
>
> 2. Create 5 lswitches and create 200 lp
_jsonrpc_monitor(struct ovsdb_monitor *dbmon,
> - struct ovsdb_jsonrpc_monitor *jsonrpc_monitor);
> -
> -void ovsdb_monitor_remove_jsonrpc_monitor(struct ovsdb_monitor *dbmon,
> - struct ovsdb_jsonrpc_monitor
*jsonrpc_monitor);
> +
On Wed, Mar 2, 2016 at 1:43 PM, Russell Bryant wrote:
>
> Prior to this commit, once a connection had been committed to the
> connection tracker, the connection would continue to be allowed, even
> if the policy defined in the ACL table changed. This patch changes
> the implementation so that exi
On Wed, Mar 9, 2016 at 1:32 PM, Ryan Moats wrote:
>
>
>
> "dev" wrote on 03/09/2016 03:12:07 PM:
>
> > From: Russell Bryant
> > To: ovs dev
> > Date: 03/09/2016 03:12 PM
> > Subject: [ovs-dev] [RFC] OVN northbound address sets
> > Sent by: "dev"
> >
> > I'd like to propose a new feature for th
S_EMPTY_INITIALIZER;
> +/* XXX Need to support "reject", treat it as "drop;" for
now. */
> +
> +if (has_stateful) {
> +/* The implementation of "drop" differs if stateful ACLs
are in
> + * use for this datapath. In that case, the ac
evious call to ct_next.
> +with it by a previous call to ct_next. When
> +the ct_mark=VALUE parameter is supplied, ct_mark will be set
> +to the 32-bit integer indicated by VALUE on the connection
> + tracking entry.
if you want processing to continue in the next
table,
> + you must execute the next action after
> +ct_commit.
> +
>
>
>
> --
> 2.5.0
>
Acked-by: Han Zhou
--
Best regards,
Han
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Wed, Mar 9, 2016 at 11:11 PM, Ben Pfaff wrote:
>
> Beyond supporting this usage model, the basic requirements for the OVN
> use case are:
>
> - Size: 20 MB to 100 MB of data (estimated database size to hold
> data for our target scale of 1,000 hypervisors and 20,000
> logical po
I replied to the older version, repost it here:
On Thu, Mar 10, 2016 at 4:01 PM, Ben Pfaff wrote:
>
> Beyond supporting this usage model, the basic requirements for the OVN
> use case are:
>
> - Size: 20 MB to 100 MB of data (estimated database size to hold
> data for our target scale o
On Thu, Mar 10, 2016 at 5:45 PM, Ben Pfaff wrote:
>
> On Thu, Mar 10, 2016 at 05:31:18PM -0800, Ben Pfaff wrote:
> > I have been considering this as a minimum interesting scale. It's hard
> > for me to know what the interesting scale range is. I am really happy
> > to hear what is important to y
Localnet port is now able to connect vif ports on different HVs.
Change the test case accordingly.
Signed-off-by: Han Zhou
---
tests/ovn.at | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/tests/ovn.at b/tests/ovn.at
index 5cb7d8b..ed84717
On Thu, Mar 17, 2016 at 8:59 AM, Ben Pfaff wrote:
>
> On Wed, Mar 16, 2016 at 10:38:46PM -0700, Han Zhou wrote:
> > On Wed, Mar 16, 2016 at 10:03 PM, Ben Pfaff wrote:
> >
> > > On Wed, Mar 16, 2016 at 08:55:35PM -0700, Han Zhou wrote:
> > > > bitwise
On Tue, Mar 15, 2016 at 11:29 PM, Russell Bryant wrote:
>
>
> On Sun, Mar 13, 2016 at 4:53 PM, Han Zhou wrote:
>
>> Localnet port is now able to connect vif ports on different HVs.
>> Change the test case accordingly.
>>
>> Signed-off-by: Han Zhou
>>
On Wed, Mar 16, 2016 at 10:03 PM, Ben Pfaff wrote:
> On Wed, Mar 16, 2016 at 08:55:35PM -0700, Han Zhou wrote:
> > bitwise_rscan() is found to be hot spot in ovn-controller during OVN
> > scalability tests. It is triggered by lflow_run() when processing
> > lflow updates fr
-controller [.] lex_token_parse
+ 4.81% ovn-controller ovn-controller [.] bitwise_rscan
+ 3.62% ovn-controller ovn-controller [.] lflow_run
Signed-off-by: Han Zhou
---
lib/util.c | 33 -
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a
Localnet port is now able to connect vif ports on different HVs.
Change the test case accordingly.
Signed-off-by: Han Zhou
---
Notes:
v1->v2:
Update according to Russell's comment: add test for connectivity
between 2 lswitches on same physical network
tests/ovn
+ 8.15% ovn-controller libc-2.19.so[.] _int_malloc
+ 5.77% ovn-controller ovn-controller [.] bitwise_rscan
+ 5.49% ovn-controller libc-2.19.so[.] _int_free
Signed-off-by: Han Zhou
---
Notes:
v1->v2:
- Refactor code and fixed a bug in v1
- U
Localnet port is now able to connect vif ports on different HVs.
Change the test case accordingly.
Signed-off-by: Han Zhou
---
Notes:
v1->v2:
Update according to Russell's comment: add test for connectivity
between 2 lswitches on same physical network
tests/ovn
On Sun, Mar 20, 2016 at 9:41 AM, William Tu wrote:
>
> Hi Han Zhou,
>
> Just curious and not related to the bitwise_rscan().
> Do you get a chance to know what this kernel symbol is?
Here is the report with kernel symbols resolved.
--- before optimization ---
+ 36.27% ovn-
On Fri, Mar 11, 2016 at 1:06 PM, Ryan Moats wrote:
>
> From: RYAN D. MOATS
>
> This code changes lflow_run to do incremental process of the
> logical flow table rather than processing the full table each run.
>
> Signed-off-by: RYAN D. MOATS
> ---
> ovn/controller/binding.c|3 ++
>
On Tue, Mar 22, 2016 at 6:17 PM, Han Zhou wrote:
>
>
>
> On Fri, Mar 11, 2016 at 1:06 PM, Ryan Moats wrote:
> >
> > From: RYAN D. MOATS
> >
> > This code changes lflow_run to do incremental process of the
> > logical flow table rather than processing t
On Wed, Mar 23, 2016 at 12:28 PM, Ryan Moats wrote:
>
> Han Zhou wrote on 03/23/2016 01:39:04 PM:
>
> > From: Han Zhou
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "dev@openvswitch.org" , Russell Bryant
> >
> > Date: 03/23/2016 01:39 PM
> >
openflow tables.
Signed-off-by: Han Zhou
---
ovn/controller/lflow.c | 38 +++---
ovn/controller/lflow.h | 3 ++-
ovn/controller/ovn-controller.c | 16 +---
ovn/controller/ovn-controller.h | 6 ++
ovn/controller/patch.c | 22
On Tue, Mar 29, 2016 at 6:57 AM, Ryan Moats wrote:
>
> Acked-by: Ryan Moats
>
Ryan, thanks for the ack.
Scale testing shows very good result:
Test precondition:
2k hypervisors, 20k lports, 200 lswitches (each with a localnet port).
Test case:
step1: add 50 hypervisors (simulated on 1 BM with
minutes.
Step2 took 936 seconds.
After the change:
Step1 took less than 1 minute: 20x faster.
Step2 took 464 seconds: 2x faster.
Signed-off-by: Han Zhou
---
ovn/controller/lflow.c | 38 +++---
ovn/controller/lflow.h | 3 ++-
ovn/controller/ovn
Currently in physical_run() we added per-port loopback prevention
flows for all lports. The flows are actually required only for
local ports on the chassis. This change greatly reduces number of
flows in table 34.
Signed-off-by: Han Zhou
---
ovn/controller/physical.c | 24
On Wed, Mar 30, 2016 at 2:01 PM, Ben Pfaff wrote:
>
> On Tue, Mar 29, 2016 at 12:26:18PM -0700, Han Zhou wrote:
> > For non-local datapaths, if there are no patch ports attached, it
> > means the lflows and port bindings would never be needed on the
> > Chassis. Since lflo
On Wed, Mar 30, 2016 at 4:48 PM, Ben Pfaff wrote:
>
> On Tue, Mar 29, 2016 at 04:55:11PM -0700, Han Zhou wrote:
> > Currently in physical_run() we added per-port loopback prevention
> > flows for all lports. The flows are actually required only for
> > local ports on
On Thu, Mar 31, 2016 at 2:29 PM, Russell Bryant wrote:
>
> On Thu, Mar 31, 2016 at 11:26 AM, Marcelo E. Magallon <
> marcelo.magal...@hpe.com> wrote:
>
> > Hi Ben,
> >
> > On 03/30/2016 06:13 PM, Ben Pfaff wrote:
> >
> > I understand the technical differences between the approaches. My
question
>
On Thu, Mar 31, 2016 at 8:05 AM, Ryan Moats wrote:
> From: RYAN D. MOATS
>
> It looks like v11 and v12 had some interesting rebase issues,
> so v13 is a rebase back to master only
>
> RYAN D. MOATS (8):
> Make flow table persistent in ovn controller
> Persist lport and mcgroup indexes
> Pe
On Tue, Apr 5, 2016 at 2:24 PM, Russell Bryant wrote:
>
> This feature was originally proposed here:
>
> http://openvswitch.org/pipermail/dev/2016-March/067440.html
>
> A common use case for OVN ACLs involves needing to match a set of IP
> addresses.
>
>outport == "lp1" && ip4.src == {10.0.0
On Mon, Apr 4, 2016 at 5:58 AM, Russell Bryant wrote:
> - Each localnet logical port is implemented as a
pair of
> - patch ports, one in the integration bridge, one in a different
> - bridge, with the same
external-ids:ovn-localnet-port
> - value.
> + E
On Wednesday, April 6, 2016, Russell Bryant > wrote:
>
>
> On Wed, Apr 6, 2016 at 3:10 AM, Han Zhou wrote:
>
>>
>> On Mon, Apr 4, 2016 at 5:58 AM, Russell Bryant wrote:
>> > - Each localnet logical port is implemented as a
>> pair of
>>
On Wednesday, April 6, 2016, Russell Bryant > wrote:
>
>
> On Tue, Apr 5, 2016 at 10:03 PM, Han Zhou wrote:
>
>>
>>
>> On Tue, Apr 5, 2016 at 2:24 PM, Russell Bryant wrote:
>> >> +/* Return true if the address sets match, false otherwise. */
>
On Friday, April 8, 2016, Xiao Liang wrote:
>
> Add new column "ofname" in Interface table to configure port name reported
> to controllers with OpenFlow protocol, thus decouple OpenFlow port name
from
> device name.
>
> For example:
> # ovs-vsctl set Interface eth0 ofname=wan
> # ovs-vsct
On Sun, Apr 10, 2016 at 7:21 PM, Lei Huang wrote:
>
> Hi,
>
> In last few months we created a ovn scalability test tool, it is
implemented based on openstack/rally project, its repo is
https://github.com/l8huang/ovn-scale-test.
>
> Its basic usage is creating thounsands of ovs sandboxes(to simulat
On Mon, Apr 11, 2016 at 3:57 PM, Ben Pfaff wrote:
>
> [dropping some CCs for people I know to be on ovs-dev]
>
> On Sun, Apr 10, 2016 at 08:45:38PM -0700, Han Zhou wrote:
> > As requested by several folks and also mentioned in last week's ovn
> > meeting, we woul
On Tue, Apr 12, 2016 at 11:02 AM, Russell Bryant wrote:
>
> On Tue, Apr 12, 2016 at 1:35 PM, Mickey Spiegel
wrote:
>
> > One comment below.
> >
> > -"dev" wrote: -
> >
> > >To: Ben Pfaff
> > >From: Russell Bryant
> > >Sent by: "dev"
> > >Date: 04/12/2016 09:37AM
> > >Cc: ovs dev
> > >S
On Wed, Apr 13, 2016 at 10:35 AM, Guru Shetty wrote:
>
>
> On 28 March 2016 at 00:10, Han Zhou wrote:
>
>> For non-local datapaths, if there are no patch ports attached, it
>> means the lflows and port bindings would never be needed on the
>> Chassis. Skipping the
There are tables added recently in ovn-nb, but not mentioned in
man page of ovn-nbctl.
Signed-off-by: Han Zhou
---
ovn/utilities/ovn-nbctl.8.xml | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/ovn/utilities/ovn-nbctl.8.xml b/ovn/utilities
ovn-trace crashes when there are dhcp flows, which makes the tool
unusable. This patch is to fix the crash with a dummy dhcp_opts,
until dhcp_opts is completely supported by ovn-trace.
Signed-off-by: Han Zhou
---
ovn/utilities/ovn-trace.c | 8 +++-
1 file changed, 7 insertions(+), 1
On Tue, Sep 27, 2016 at 2:36 PM, Darrell Ball wrote:
>
> There has been enough confusion regarding arp responders in
> ovn to warrant some additional comments; hence add a
> general description regarding why they exist and document
> the special cases.
>
> The patch goes along with patch fix for
quot;These port types are skipped. Otherwise the arp
> request is received by multiple hypervisors, which all have the
> same mac binding downloaded from northd, which will cause
> redundant arp replies, confusing the originator of the arp request. "
>
Sounds good to me.
Acked
On Thu, Sep 29, 2016 at 11:31 AM, Ben Pfaff wrote:
>
> When a VM sends an ARP or an ND NS for its own IP address, it is trying to
> check for a duplicate address in the network. OVN needs to suppress the
> reply in such a case, otherwise the VM thinks that its address is a
> duplicate.
>
> Report
On Sat, Oct 1, 2016 at 4:34 PM, Darrell Ball wrote:
>
> Do not install any potential logical switch "router type"
> port arp responders. Logical router port arp responders
> should be sufficient in this respect.
> It seems a little wierd for a logical switch not proxying
> for a remote VIF to be
On Sat, Oct 1, 2016 at 4:34 PM, Darrell Ball wrote:
>
>
> - These flows are omitted for logical ports (other than router
ports)
> - that are down.
> + These flows are omitted for router type ports and other
> + logical ports that are down.
This part
This change should belong to the 1/3 patch. Each individual patch should be
complete and independent to future patches.
On Sat, Oct 1, 2016 at 4:34 PM, Darrell Ball wrote:
> If arp responders are unnecessay for logical switch
> "router type" ports. then an adjustment is necessary
> for a test.
>
On Sun, Oct 2, 2016 at 2:14 PM, Darrell Ball wrote:
>
>
>
> On Sun, Oct 2, 2016 at 11:27 AM, Han Zhou wrote:
>>
>> On Sat, Oct 1, 2016 at 4:34 PM, Darrell Ball wrote:
>> >
>> > Do not install any potential logical switch "router type"
On Mon, Oct 3, 2016 at 2:21 PM, Darrell Ball wrote:
>
>
>
> On Mon, Oct 3, 2016 at 10:54 AM, Han Zhou wrote:
>>
>>
>>
>> On Sun, Oct 2, 2016 at 2:14 PM, Darrell Ball wrote:
>> >
>> >
>> >
>> > On Sun, Oct 2, 2016 at 11:27
On Tue, Oct 4, 2016 at 10:16 AM, Darrell Ball wrote:
>
>
>
> On Mon, Oct 3, 2016 at 3:16 PM, Han Zhou wrote:
>>
>>
>>
>> On Mon, Oct 3, 2016 at 2:21 PM, Darrell Ball wrote:
>> >
>> >
>> >
>> > On Mon, Oct 3, 2016 at 10:54
packets, as there would be some additional flow cost for this
> +and the value appears limited.
Maybe we don't even need to mention this if we don't want to skip this kind
of packet. If there is no such case, it means we don't need to add flows to
skip it; if there is such
On Thu, Oct 20, 2016 at 11:51 AM, Russell Bryant wrote:
>
> On Thu, Oct 20, 2016 at 1:47 PM, Ben Pfaff wrote:
>
> > On Thu, Oct 13, 2016 at 07:32:53PM +0530, Numan Siddique wrote:
> >
> > > 5) Remove support from ovn-controller updating the 'Chassis.hv_cfg'
> > > column and handle the side effect
The exiting explanation didn't tell user the conntrack capability
and user may be unaware of the stateful feature of OVS.
Signed-off-by: Han Zhou
---
FAQ.md | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/FAQ.md b/FAQ.md
index 420e40e..776b8f6 100644
--- a/FAQ.md
Hi,
I love Gal's idea of having IP field, which make it possible for a
pure L3 overlay (i.e. no L2 header encapsulated), with the help of ARP
responders on each transport node.
It would be efficient in cloud env where L3 is sufficient.
Han
On Tue, Jul 14, 2015 at 9:08 PM, Gal Sagie wrote:
> Thi
Speedup is ~250%.
Hope this feature is useful for those who rely on VXLAN.
Let me know your thoughts and any comments are welcome!
Signed-off-by: Han Zhou
---
datapath/linux/compat/include/net/vxlan.h | 28 +-
datapath/linux/compat/vxlan.c | 153
Repost it since the original one was blocked by some spam filters.
@Jesse, could you help review it from technical point of view? If this
looks good I can then make it optional and configurable. Thanks a lot!
-Han
On Mon, May 12, 2014 at 4:04 PM, Han Zhou wrote:
> This patch implements vx
up failure of processing the updates.
http://openvswitch.org/pipermail/dev/2015-December/063406.html
This patch fixes the issue by using dedicated cache for each version.
Signed-off-by: Han Zhou
---
ovsdb/monitor.c | 40 +++-
1 file changed, 27 inserti
I dig deeper and proposed a fix of the problem:
https://patchwork.ozlabs.org/patch/557280/
It worked for me :)
On Mon, Dec 14, 2015 at 10:52 PM, Han Zhou wrote:
> Hi,
>
> With latest ovs code, there comes below kind of error when ovn-northd is
> receiving updates from ovsdb-serv
up failure of processing the updates.
This patch fixes the issue by using dedicated cache for each version.
Signed-off-by: Han Zhou
---
ovsdb/monitor.c | 40 +++-
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/ovsdb/monitor.c b/ovsdb/monit
For some reason my patch was blocked by the mailinglist, so I just removed
the http link from commit message and resent. Now it is seen in the
mailinglist:
http://openvswitch.org/pipermail/dev/2015-December/063461.html
Sorry for the spam.
On Tue, Dec 15, 2015 at 6:58 PM, Han Zhou wrote:
>
Justin, you are right. I am sorry it was my NTP out of sync when I sent the
first patch, so the message was shown up in the middle of the earlier
messages. Sorry for the confusion!
On Wed, Dec 16, 2015 at 12:08 AM, Justin Pettit wrote:
>
> > On Dec 15, 2015, at 7:13 PM, Han Zh
Hi Andy,
Thanks for your review.
On Thu, Dec 17, 2015 at 2:00 PM, Andy Zhou wrote:
>
>
> On Tue, Dec 15, 2015 at 7:06 PM, Han Zhou wrote:
>
>> Cached json objects were reused when sending notifications to
>> clients. This created a problem when there were different
On Thu, Dec 17, 2015 at 4:33 PM, Han Zhou wrote:
> Hi Andy,
>
> Thanks for your review.
>
>
> On Thu, Dec 17, 2015 at 2:00 PM, Andy Zhou wrote:
>
>>
>>
>> On Tue, Dec 15, 2015 at 7:06 PM, Han Zhou wrote:
>>
>>> Cached json objects were
up failure of processing the updates.
This patch fixes the issue by including version in cache node.
Signed-off-by: Han Zhou
---
Notes:
v1 -> v2: add version to cache node and add it to hash key, according to
suggestion by Andy Zhou
ovsdb/monitor.c | 18 +
On Mon, Dec 21, 2015 at 1:59 PM, Ben Pfaff wrote:
> On Mon, Dec 21, 2015 at 03:03:42PM -0500, Russell Bryant wrote:
> > On 12/21/2015 02:52 PM, Ben Pfaff wrote:
> > > On Mon, Dec 21, 2015 at 10:39:29AM -0500, Russell Bryant wrote:
> > >> On 12/21/2015 09:55 AM, Numan Siddique wrote:
> > >>> On 12
Currently we have "localnet" in OVN to connect VIF to physical network, but
there seems to be no way to support intra-hypervisor communication with
exiting model mentioned in ovn-sb.xml:
localnet
A connection to a locally accessible network from each
ov
.
> @@ -860,7 +875,7 @@ as hv2 ovs-ofctl -O OpenFlow13 dump-flows br-int
>
> # Now check the packets actually received against the ones expected.
> for i in 1 2; do
> -for j in 1 2; do
> +for j in 1 2 3 4; do
> file=hv$i/vif$i$j-tx.pcap
> echo $file
> $PYTHON "$top_srcdir/utilities/ovs-pcap.in" $file | trim_zeros >
> $i$j.packets
> --
> 2.5.0
>
>
Port 22 and 44 are not used, but that's not a problem.
Acked-by: Han Zhou >
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Thu, Jan 14, 2016 at 5:08 PM, Ben Pfaff wrote:
> On Thu, Jan 14, 2016 at 05:05:52PM -0800, Han Zhou wrote:
> > Acked-by: Han Zhou >
>
> What?
>
Another bad example of copy/paste :(
___
dev mailing list
dev@openvswitch.org
h
localnet port is on a logical switch with
> another logical port with an associated local VIF.
>
> A nice side effect of this fix is that the code in physical.c got a lot
> simpler, as localnet ports are now handled mostly like local VIFs.
>
> Fixes: c02819293d52 ("ovn: Add &q
/binding.h| 3 ++-
> ovn/controller/ovn-controller.c | 18 --
> ovn/controller/physical.c | 25 +++--
> ovn/controller/physical.h | 3 ++-
> 5 files changed, 47 insertions(+), 27 deletions(-)
>
Acked-By: Han Zhou
--
Best regards,
Han
_
gt; simpler, as localnet ports are now handled mostly like local VIFs.
> >
> > Fixes: c02819293d52 ("ovn: Add "localnet" logical port type.")
> > Reported-by: Han Zhou
> > Reported-at:
http://openvswitch.org/pipermail/dev/2016-January/064413.html
>
On Fri, Jan 22, 2016 at 7:06 AM, Numan Siddique wrote:
>
> Hi All,
>
> I am working on the port security feature in ovn and implementing as per
the port security proposal defined here [1].
>
> If a logical port has one mac and multiple IP addresses (both ipv4 and
ipv6), as per this proposal, Logic
I went into the "bad key length" in below datapath flow in a test
environment:
recirc_id(0x109),in_port(5),ct_state(-new+est-rel-inv+trk),eth(src=fa:16:3e:00:49:66,dst=fa:16:3e:ca:4a:20),eth_type(0x0800),ipv4(src=
22.22.22.4/255.255.255.252,dst=22.22.23.4,tos=0/0x3,ttl=64,frag=no),
packets:4, byte
rt is on a logical switch with
> another logical port with an associated local VIF.
>
> A nice side effect of this fix is that the code in physical.c got a lot
> simpler, as localnet ports are now handled mostly like local VIFs.
>
> Fixes: c02819293d52 ("ovn: Add "localnet
On Fri, Jan 22, 2016 at 6:17 PM, Han Zhou wrote:
>
> Regarding the functionality of port-security itself, I am not sure how
would it be supported for ls_out_port_sec. If a dst MAC is not recognised
in ls_in_l2_lkup stage, it is meaningless to have it allowed in
ls_out_port_sec, because the
On Mon, Jan 25, 2016 at 2:02 PM, Russell Bryant wrote:
>
> Previously, all ct() actions applied to localnet ports used the default
> conntrack zone. We should allocate a ct zone ID for all localnet ports
> just like we do for all local VIFs so that none of our connection
> tracking interferes wit
1 - 100 of 147 matches
Mail list logo
