The original message was received at Thu, 1 Sep 2016 11:27:04 +0530
from [5.6.209.9]
- The following addresses had permanent fatal errors -
- Transcript of the session follows -
... while talking to server 119.183.12.52:
>>> RCPT To:
<<<
Hi, Jesse:
Thanks a lot for your clear reply. Physical NIC maybe conforms to
RFC2819 as follows:
etherStatsPkts64Octets OBJECT-TYPE
SYNTAX Counter32
UNITS "Packets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets (including bad
packets) received that were 64
Hi Guru,
I did not find the networking-ovn plugin for l3 gateway router.
Is it still under development?
Thanks.
Best Regards
Steve Ruan(阮诗新)
Tel: (86-021)60928749,
Address: 5/F, Building 10, 399 Ke Yuan Road, Zhangjiang High-Tech Park,
Shanghai 201203, PRC
上海浦东新区张江高科园区科苑路399号10号楼6楼
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
From: Babu Shanmugam
This patch adds support to start_ovsdb() function in ovn-ctl to start the
ovn db servers in backup mode. This can be done in the following ways
1. Use parameters --ovn-nb-sync-from-addr and --ovn-sb-sync-from-addr to
set the addresses of the active
On Wed, Aug 31, 2016 at 07:33:06PM -0400, Russell Bryant wrote:
> On Wed, Aug 31, 2016 at 5:25 PM, Ben Pfaff wrote:
>
> > This commit reverts encaps.c to its content just before commit 1d45d5a9666d
> > (ovn-controller: Change encaps_run to work incrementally.). I then
> >
On Thu, Sep 01, 2016 at 12:20:46AM +, Ramu Ramamurthy wrote:
> Since dhcp responses are important for debugging the vif lifecycle,
> we want to log them at info level which is the default log level.
> A logsearch (on macaddr) can quickly tell the dhcp status using
> such messages. There is no
On Wed, Aug 31, 2016 at 6:48 PM, Joe Stringer wrote:
> On 31 August 2016 at 14:52, Daniele Di Proietto
> wrote:
> > Open vSwitch controls the MTU of internal ports and sets it to the
> > minimum of physical ports MTU on the same bridge.
> >
> > Commit
Added the '--no-sync' option base on feedbacks of current
implementation.
Added appctl command "ovsdb-server/sync-status" based on feedbacks
of current implementation.
Added the RPL_S_INIT state in the state machine. This state is
not strictly necessary for the replication state machine, but is
On Tue, Aug 30, 2016 at 2:35 PM, Ben Pfaff wrote:
> On Fri, Aug 26, 2016 at 04:15:53PM -0700, Andy Zhou wrote:
> > Current replication uses blocking transactions, which are error prone
> > in practice, especially in handling RPC connection flapping to the
> > active server.
> >
> >
On 31 August 2016 at 14:52, Daniele Di Proietto wrote:
> Open vSwitch controls the MTU of internal ports and sets it to the
> minimum of physical ports MTU on the same bridge.
>
> Commit 47bf118665a3("ofproto: Always set MTU for new internal ports.")
> made this more
On 31/08/2016 11:32, "Jarno Rajahalme" wrote:
>I’d put the registers and metadata field to the ‘false’ and also maybe
>non-writeable fields (ether type, frags, nw_proto, etc.) in to
>OVS_NOT_REACHED() case, just in case.
>
> Jarno
Agreed, done
Thanks,
Daniele
>
>> On Aug
On 31/08/2016 10:38, "Jesse Gross" wrote:
>On Tue, Aug 30, 2016 at 6:47 PM, Daniele Di Proietto
> wrote:
>> When translating a set action we also unwildcard the field in question.
>> This is done to correctly translate set actions with the value
Sorry for missing one of your points in the previous review.
I will submit v3 patch to support that function.
> On Aug 31, 2016, at 11:11 PM, Guru Shetty wrote:
>
> On 29 August 2016 at 20:12, nickcooper-zhangtonghao
>
Å|0;«)3`Ïü¶¸^ÞÊ6Éuh½Ïµó"VÖð
tÔÊn¨Õ¼DzÎßD5åPÃqÇjöòÄs¶,ÎLlYl3Ĥº7UNóÖß`Ó¶&¢`8»0MåçZ>{H¦éjÏVAB·áhÚ¡DVlä´×ª'h)¡
¨:'ï¥ø53öâ8¶ ¯ÕÞÐc¶ªS>\ÉAêû[ú[\%·¨Ñé#Ãî
QSÕçwjp~Dvëãé~t%QîmHÏÌÞz%g{µy7Ý//u3éø·ñvàyF«¥
mvòK¶ÆVÇ878ûj
úPS$ÔàwÕVø)Öpw~{6Ez¿
I
*nÌO#´fÄ®ü¹{ëMÚþn`>¬
This message was not delivered due to the following reason:
Your message was not delivered because the destination server was
not reachable 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 there
Since dhcp responses are important for debugging the vif lifecycle,
we want to log them at info level which is the default log level.
A logsearch (on macaddr) can quickly tell the dhcp status using
such messages. There is no need to rate limit such logs
because, we expect dhcp messages to be at
Voice Message Arrived on Friday, Aug 26 @ 5: 25 AM
Name: Outside Caller
Number: Unavailable
Duration: 1m 38s
_
OPENVSWITCH.COM SV9100 InMail
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Voice Message Arrived on Friday, Aug 26 @ 8: 25 AM
Name: Outside Caller
Number: Unavailable
Duration: 1m 34s
_
OPENVSWITCH.COM SV9100 InMail
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Hi Nithin,
Instead of removing the assertion, can you change it to:
ASSERT(!key->tunKey.dst || offset == OvsGetFlowL2Offset(>tunKey));
I fixed it for OvsLookupFlow but somehow overlooked OvsHashFlow in my
Geneve patch.
Best regards,
Yin Lin
On Wed, Aug 31, 2016 at 3:33 AM, Nithin Raju
Voice Message Arrived on Friday, Aug 26 @ 5: 35 AM
Name: Outside Caller
Number: Unavailable
Duration: 2m 21s
_
OPENVSWITCH.COM SV9100 InMail
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Wed, Aug 31, 2016 at 5:25 PM, Ben Pfaff wrote:
> This commit reverts encaps.c to its content just before commit 1d45d5a9666d
> (ovn-controller: Change encaps_run to work incrementally.). I then
> reintroduced the UDP checksum support originallly added in commit
> 36283d7884f3
On Wed, Aug 31, 2016 at 5:25 PM, Ben Pfaff wrote:
> In a call like "ovsrec_bridge_update_ports_delvalue(bridge, port)",
> there's
> no reason for the port argument to be nonconst, because the call doesn't
> do anything to the port at all--it only searches the list of ports in the
>
On Wed, Aug 31, 2016 at 2:52 PM, Daniele Di Proietto wrote:
> Open vSwitch controls the MTU of internal ports and sets it to the
> minimum of physical ports MTU on the same bridge.
>
> Commit 47bf118665a3("ofproto: Always set MTU for new internal ports.")
> made this
Voice Message Arrived on Friday, Aug 26 @ 5: 39 AM
Name: Outside Caller
Number: Unavailable
Duration: 3m 51s
_
OPENVSWITCH.COM SV9100 InMail
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Ben Pfaff wrote on 08/31/2016 04:26:37 PM:
> From: Ben Pfaff
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: ovs dev , Jesse Gross
> Date: 08/31/2016 04:26 PM
> Subject: Re: [ovs-dev] [PATCH] ovn-controller: Convert encaps module
> back
On 31 August 2016 at 13:18, Jarno Rajahalme wrote:
> With a minor question below,
>
> Acked-by: Jarno Rajahalme
>
>> On Aug 31, 2016, at 11:06 AM, Joe Stringer wrote:
>>
>> If a revalidator dumps/revalidates a flow during the 'dump' phase,
>>
On 31 August 2016 at 13:17, Jarno Rajahalme wrote:
> With small nits below,
>
> Acked-by: Jarno Rajahalme
Thanks, I also noticed a couple of VLOGs missing their ratelimiters.
>> @@ -334,9 +345,9 @@ static int ukey_create_from_dpif_flow(const struct udpif
>> *,
>>
Voice Message Arrived on Friday, Aug 26 @ 9: 20 AM
Name: Outside Caller
Number: Unavailable
Duration: 0m 22s
_
OPENVSWITCH.COM SV9100 InMail
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On 31 August 2016 at 13:16, Jarno Rajahalme wrote:
> With one question below,
>
> Acked-by: Jarno Rajahalme
Thanks for the review,
>> On Aug 31, 2016, at 11:06 AM, Joe Stringer wrote:
>>
>> Currently when processing a batch of upcalls, all datapath
Voice Message Arrived on Friday, Aug 26 @ 9: 43 AM
Name: Outside Caller
Number: Unavailable
Duration: 2m 43s
_
OPENVSWITCH.COM SV9100 InMail
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On 30/08/2016 18:06, "Daniele Di Proietto" wrote:
>
>
>
>
>
>On 30/08/2016 15:32, "Ben Pfaff" wrote:
>
>>On Tue, Aug 30, 2016 at 11:41:15AM -0700, Daniele Di Proietto wrote:
>>> We only changed the MTU of new internal ports if it is bigger than the
>>>
Open vSwitch controls the MTU of internal ports and sets it to the
minimum of physical ports MTU on the same bridge.
Commit 47bf118665a3("ofproto: Always set MTU for new internal ports.")
made this more consistent. Now the MTU is always set, even when the
bridge doesn't have any physical ports
Voice Message Arrived on Friday, Aug 26 @ 8: 43 AM
Name: Outside Caller
Number: Unavailable
Duration: 3m 32s
_
OPENVSWITCH.COM SV9100 InMail
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Wed, Aug 31, 2016 at 12:59:05PM -0500, Ryan Moats wrote:
> Ben Pfaff wrote on 08/31/2016 12:46:17 PM:
>
> > From: Ben Pfaff
> > To: Jesse Gross
> > Cc: Ryan Moats/Omaha/IBM@IBMUS, ovs dev
> > Date: 08/31/2016 12:46 PM
> >
In a call like "ovsrec_bridge_update_ports_delvalue(bridge, port)", there's
no reason for the port argument to be nonconst, because the call doesn't
do anything to the port at all--it only searches the list of ports in the
bridge for that particular port and, if it finds it, removes it.
This commit reverts encaps.c to its content just before commit 1d45d5a9666d
(ovn-controller: Change encaps_run to work incrementally.). I then
reintroduced the UDP checksum support originallly added in commit
36283d7884f3 (ovn-controller: Use UDP checksums when creating Geneve
tunnels.) I also
The Open vSwitch team will host our third annual conference focused on Open
vSwitch and OVN on November 7 and 8, 2016, to be held at the San Jose
Doubletree.
Topics that may be considered include:
* The future of Open vSwitch (e.g., P4 and eBPF).
* NAT, DPI, and stateful processing with Open
Singed-off-by : Anand Kumar
---
INSTALL.Windows.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/INSTALL.Windows.md b/INSTALL.Windows.md
index 6b0f5d8..59f3936 100644
--- a/INSTALL.Windows.md
+++ b/INSTALL.Windows.md
@@ -134,7 +134,7 @@ For example,
Ben Pfaff wrote on 08/31/2016 02:45:36 PM:
> From: Ben Pfaff
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: dev@openvswitch.org
> Date: 08/31/2016 02:45 PM
> Subject: Re: [ovs-dev] [ovs-dev, v2,3/4] Unpersist data structures
> for address sets.
>
> On Wed, Aug 31, 2016 at
With a minor question below,
Acked-by: Jarno Rajahalme
> On Aug 31, 2016, at 11:06 AM, Joe Stringer wrote:
>
> If a revalidator dumps/revalidates a flow during the 'dump' phase,
> resulting in the deletion of the flow, then ukey->flow_exists is set to
> false, and
With small nits below,
Acked-by: Jarno Rajahalme
> On Aug 31, 2016, at 11:06 AM, Joe Stringer wrote:
>
> Ukeys already have a well-defined lifetime that starts from being
> created, inserted into the umaps, having the corresponding flow
> installed, then the flow
With one question below,
Acked-by: Jarno Rajahalme
> On Aug 31, 2016, at 11:06 AM, Joe Stringer wrote:
>
> Currently when processing a batch of upcalls, all datapath operations
> are first initialized, then later the corresponding ukeys are installed.
> If the
Acked-by: Jarno Rajahalme
> On Aug 31, 2016, at 11:06 AM, Joe Stringer wrote:
>
> Signed-off-by: Joe Stringer
> ---
> v2: First post
> ---
> ofproto/ofproto-dpif-upcall.c | 24
> 1 file changed, 8 insertions(+), 16
On Tue, 2016-08-30 at 17:35 -0400, David Hill wrote:
> Hello sir,
>
> I do not understand either but that's what's happening. It's a
> fiber adapter so maybe the driver says it's supported and when trying to
> request values from the nic itself it fails because it's no longer
>
On Wed, Aug 31, 2016 at 01:51:51PM -0500, Ryan Moats wrote:
>
>
> "dev" wrote on 08/31/2016 12:53:27 PM:
>
> > From: Ryan Moats/Omaha/IBM@IBMUS
> > To: Ben Pfaff
> > Cc: dev@openvswitch.org
> > Date: 08/31/2016 12:53 PM
> > Subject: Re: [ovs-dev]
"dev" wrote on 08/31/2016 12:53:27 PM:
> From: Ryan Moats/Omaha/IBM@IBMUS
> To: Ben Pfaff
> Cc: dev@openvswitch.org
> Date: 08/31/2016 12:53 PM
> Subject: Re: [ovs-dev] [ovs-dev, v2, 3/4] Unpersist data structures
> for address sets.
> Sent by: "dev"
I’d put the registers and metadata field to the ‘false’ and also maybe
non-writeable fields (ether type, frags, nw_proto, etc.) in to
OVS_NOT_REACHED() case, just in case.
Jarno
> On Aug 31, 2016, at 10:38 AM, Jesse Gross wrote:
>
> On Tue, Aug 30, 2016 at 6:47 PM,
On Wed, Aug 31, 2016 at 5:36 PM, Numan Siddique wrote:
>
>
> On Wed, Aug 31, 2016 at 12:03 AM, Andy Zhou wrote:
>
>>
>>
>> On Tue, Aug 30, 2016 at 4:17 AM, Numan Siddique
>> wrote:
>>
>>>
>>>
>>> On Tue, Aug 30, 2016 at 1:11 AM, Andy
> On Aug 31, 2016, at 9:55 AM, Ben Pfaff wrote:
>
> On Wed, Aug 31, 2016 at 08:53:20AM -0700, Jarno Rajahalme wrote:
>> Pushed to master. How about branch-2.6?
>
> I'm inclined to put both of these on branch-2.6 as well.
Done.
Jarno
On 30 August 2016 at 13:45, Lance Richardson wrote:
> Add a test case to check connectivity over an OVS bond, using a
> Linux bond over veth interfaces.
>
> Also added a new macro "ADD_VETH_BOND", modeled after "ADD_VETH",
> in anticipation of future additional bonding test
Recent bugs[1] have highlighted a particular situation where we may handle
significant traffic in userspace via the upcall mechanism either due to flow
table changes, or when bugs in translation logic result in unexpected deletion
of datapath flows.
The basic logic is this:
* A high-throughput
On Wed, Aug 31, 2016 at 12:59:05PM -0500, Ryan Moats wrote:
> Ben Pfaff wrote on 08/31/2016 12:46:17 PM:
>
> > From: Ben Pfaff
> > To: Jesse Gross
> > Cc: Ryan Moats/Omaha/IBM@IBMUS, ovs dev
> > Date: 08/31/2016 12:46 PM
> >
Currently when processing a batch of upcalls, all datapath operations
are first initialized, then later the corresponding ukeys are installed.
If the ukey_install fails at this later point, then the code needs to
backtrack a bit to delete the ukey and skip using the initialized
datapath op.
It's
If a revalidator dumps/revalidates a flow during the 'dump' phase,
resulting in the deletion of the flow, then ukey->flow_exists is set to
false, and the ukey is kept around until the 'sweep' phase. The ukey is
kept around to ensure that cases like duplicated dumps from the
datapaths do not result
Signed-off-by: Joe Stringer
---
v2: First post
---
ofproto/ofproto-dpif-upcall.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index e4473080ad65..e7fcdd28c9ff 100644
---
Ukeys already have a well-defined lifetime that starts from being
created, inserted into the umaps, having the corresponding flow
installed, then the flow deleted, the ukey removed from the umap,
rcu-deferral of its deletion, and finally freedom.
However, until now it's all been represented
On 31 August 2016 at 00:45, Paul Boca wrote:
> Hi Guru,
>
>
>
> There are other tests that check if the daemon is running fine.
>
> In my opinion we could skip this test on Windows and let it on Linux to
> run.
>
All right. I applied this.
>
>
> Paul
>
>
>
>
Ben Pfaff wrote on 08/31/2016 12:46:17 PM:
> From: Ben Pfaff
> To: Jesse Gross
> Cc: Ryan Moats/Omaha/IBM@IBMUS, ovs dev
> Date: 08/31/2016 12:46 PM
> Subject: Re: [ovs-dev] [PATCH] ovn-controller: Convert encaps module
> back
Ben Pfaff wrote on 08/31/2016 12:38:34 PM:
> From: Ben Pfaff
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: dev@openvswitch.org
> Date: 08/31/2016 12:38 PM
> Subject: Re: [ovs-dev,v2,3/4] Unpersist data structures for address sets.
>
> On Wed, Aug 31, 2016 at 03:22:45PM
Thanks for fixing this.
Acked-by: Sairam Venugopal
On 8/31/16, 3:33 AM, "Nithin Raju" wrote:
>Since the Geneve changes, the key->l2.offset will no longer be 0 when
>the tunnel key is valid within the OVS flow key. key->l2.offset would
>be determined by
On Tue, Aug 30, 2016 at 09:04:10AM -0700, Jesse Gross wrote:
> On Sun, Aug 28, 2016 at 3:51 PM, Ryan Moats wrote:
> > diff --git a/ovn/controller/encaps.c b/ovn/controller/encaps.c
> > index d99ba05..87f 100644
> > --- a/ovn/controller/encaps.c
> > +++
On Tue, Aug 30, 2016 at 6:47 PM, Daniele Di Proietto
wrote:
> When translating a set action we also unwildcard the field in question.
> This is done to correctly translate set actions with the value identical
> to the ingress flow, like in the following example:
>
> flow
On Wed, Aug 31, 2016 at 03:22:45PM +, Ryan Moats wrote:
> With the removal of incremental processing, it is no longer
> necessary to persist the data structures for storing address
> sets. Simplify things by removing this complexity.
>
> Side effect: fixed a memory leak in
On Wed, Aug 31, 2016 at 03:22:43PM +, Ryan Moats wrote:
> As [1] indicates, incremental processing hasn't resulted
> in an improvement worth the complexity it has added.
> This patch backs out all of the code specific to incremental
> processing, along with the persisting of OF flows,
>
On Wed, Aug 31, 2016 at 09:33:24AM -0700, Amitabha Biswas wrote:
> Fixes: 19cd0a87
>
> Signed-off-by: Amitabha Biswas
> Acked-by: Numan Siddique
Thanks, applied to master.
I adjusted the commit message to match our usual style:
ovs-monitor-ipsec:
On Wed, Aug 31, 2016 at 08:53:20AM -0700, Jarno Rajahalme wrote:
> Pushed to master. How about branch-2.6?
I'm inclined to put both of these on branch-2.6 as well.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Wed, Aug 31, 2016 at 2:30 AM, Yang, Zhiyong wrote:
> Hi, all:
>
> Physical NIC has a set of hardware counters, such as
> u64 prc64;
> u64 prc127;
> u64 prc255; etc.
> DPDK counts the prc64 in two ways. Physical NIC counts prc64 with CRC by
> hardware. Virtio computes
Fixes: 19cd0a87
Signed-off-by: Amitabha Biswas
Acked-by: Numan Siddique
---
debian/ovs-monitor-ipsec | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/ovs-monitor-ipsec b/debian/ovs-monitor-ipsec
index e6617b0..6bc26aa 100755
> On Aug 30, 2016, at 8:55 AM, Ben Pfaff wrote:
>
> On Tue, Aug 23, 2016 at 05:51:36PM -0700, Jarno Rajahalme wrote:
>> Make the immediate data member 'src_imm' of a learn spec allocated at
>> the end of the action for just the right size. This, together with
>> some structure
> On Aug 30, 2016, at 9:06 AM, Ben Pfaff wrote:
>
> On Tue, Aug 23, 2016 at 05:51:37PM -0700, Jarno Rajahalme wrote:
>> Change the value and mask to be added to the end of the set field
>> action without any extra bytes, exept for the usual ofp-actions
>> padding to 8 bytes.
This patch converts the encaps module back to full processing, but
does not remove all persistence of associated data strcutures.
Signed-off-by: Ryan Moats
---
ovn/controller/encaps.c | 33 ++---
1 file changed, 14 insertions(+), 19 deletions(-)
With the removal of incremental processing, it is no longer
necessary to persist the data structures for storing address
sets. Simplify things by removing this complexity.
Side effect: fixed a memory leak in expr_macros_destroy that
is evidenced by this change.
Signed-off-by: Ryan Moats
As discussed in [1], what the incremental processing code
actually accomplished was that the ovn-controller would
be "quiet" and not burn CPU when things weren't changing.
This patch set recreates this state by calculating whether
changes have occured that would require a full calculation
to be
As [1] indicates, incremental processing hasn't resulted
in an improvement worth the complexity it has added.
This patch backs out all of the code specific to incremental
processing, along with the persisting of OF flows,
logical ports, multicast groups, all_lports, local and patched
datapaths.
This patch set removes incremental processing and replaces it
with quiet mode: ovn-controller first tests to see if recalculation
is necessary and if so, does a full calculation.
Side effect of this is that almost all data persistence is also reverted.
The exception is the persistence in the
On 29 August 2016 at 20:12, nickcooper-zhangtonghao <
nickcooper-zhangtong...@opencloud.tech> wrote:
> Add a name column for the load balancer. This must be unique among
> all load balancers. This name has no special meaning or purpose
> other than to provide convenience for human interaction
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
The original message was received at Wed, 31 Aug 2016 18:32:51 +0530 from
6.228.10.129
- The following addresses had permanent fatal errors -
- Transcript of session follows -
... while talking to 149.119.230.11:
554 Service unavailable; [172.144.23.229]
The message was not delivered due to the following reason:
Your message was not 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 there is
On Wednesday 31 August 2016 02:42 AM, Andy Zhou wrote:
On Thu, Aug 25, 2016 at 6:48 AM, > wrote:
This patch adds support to start_ovsdb() function in ovn-ctl to
start the
ovn db servers in standby mode. This can be done in the
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Wed, Aug 31, 2016 at 12:03 AM, Andy Zhou wrote:
>
>
> On Tue, Aug 30, 2016 at 4:17 AM, Numan Siddique
> wrote:
>
>>
>>
>> On Tue, Aug 30, 2016 at 1:11 AM, Andy Zhou wrote:
>>
>>>
>>>
>>> On Mon, Aug 29, 2016 at 3:14 AM, Numan Siddique
Amitabha Biswas wrote on 08/31/2016 01:35:07 AM:
> From: Amitabha Biswas
> To: dev@openvswitch.org
> Cc: russ...@ovn.org, Richard Theis/Rochester/IBM@IBMUS, Amitabha
> Biswas/San Jose/IBM@IBMUS
> Date: 08/31/2016 01:35 AM
> Subject: [PATCH]
On Wed, Aug 31, 2016 at 12:05 PM, Amitabha Biswas
wrote:
> ---
> debian/ovs-monitor-ipsec | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/debian/ovs-monitor-ipsec b/debian/ovs-monitor-ipsec
> index e6617b0..6bc26aa 100755
> ---
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Since the Geneve changes, the key->l2.offset will no longer be 0 when
the tunnel key is valid within the OVS flow key. key->l2.offset would
be determined by the amount of tunnel options.
Signed-off-by: Nithin Raju
---
datapath-windows/ovsext/DpInternal.h | 9 ++---
Hi, all:
Physical NIC has a set of hardware counters, such as
u64 prc64;
u64 prc127;
u64 prc255; etc.
DPDK counts the prc64 in two ways. Physical NIC counts prc64 with CRC by
hardware. Virtio computes the counter like prc64 without CRC. This will cause
the conflict, when a 64 packet from outer
Hi everyone,
I am trying to figure out how to bring my br0 bridge up every time my
server boots.
usually i have to follow these steps,
sudo ovs-vsctl add-br br0
> sudo ovs-vsctl add-port br0 enp1s0
> sudo ifconfig enp1s0 0.0.0.0
> sudo dhclient br0
>
I tried to follow
The original message was received at Wed, 31 Aug 2016 13:42:20 +0530
from usal.es [29.197.93.198]
- The following addresses had permanent fatal errors -
- Transcript of the session follows -
... while talking to mail server openvswitch.org.:
554 Service
This message was undeliverable due to the following reason(s):
Your message was not delivered because the destination server was
not reachable 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
Hi Guru,
There are other tests that check if the daemon is running fine.
In my opinion we could skip this test on Windows and let it on Linux to run.
Paul
From: Guru Shetty [mailto:g...@ovn.org]
Sent: Tuesday, August 30, 2016 6:18 PM
To: Paul Boca
Cc: dev@openvswitch.org
Subject: Re: [ovs-dev]
The original message was received at Wed, 31 Aug 2016 12:57:31 +0530 from
openvswitch.org [210.6.150.164]
- The following addresses had permanent fatal errors -
dev@openvswitch.org
___
dev mailing list
dev@openvswitch.org
v10 -> v11
- Moved the DSCP marking at a later stage as suggested by Mickey Spiegel
- Update the documentation for the DSCP in ovn northd's man page template
Babu Shanmugam (2):
Check and allocate free qdisc queue id for ports with qos parameters
DSCP marking on packets egressing VIF
1 - 100 of 103 matches
Mail list logo