I am trying to simulate traffic in test cases to test IPFIX feature.
For normal traffic, I can use "ovs-appctl netdev-dummy/receive " to simulate
it, just refer to the netflow and sflow cases in tests/ofproto-dpif.at
And I can capture the IPFIX packets on lo interface as expected.
But fo
The only user of this function was removed in the previous patch, so
remove it.
Signed-off-by: Joe Stringer
---
ofproto/ofproto-dpif.c | 12
ofproto/ofproto-provider.h |2 --
ofproto/ofproto.c | 41 -
3 files changed, 55 d
Caching the results of xlate_learn was previously dependent on the state
of the 'may_learn' flag. This meant that if the caller did not specify
that this flow may learn, then a learn entry would not be cached.
However, the xlate_cache tends to be used on a recurring basis, so
failing to cache the l
Thank you for the reviews. Series applied with an incremental shown below,
Jarno
On Jun 2, 2014, at 9:24 PM, YAMAMOTO Takashi wrote:
>> ovsrcu_set() and ovsrcu_init() look like functions, so users are
>> justified in expecting the arguments to be evalueated before any of
>
> evaluated
>
Th
Ryan,
See comments below.
Jarno
On Jun 2, 2014, at 3:54 PM, Ryan Wilson wrote:
> When a bridge of datatype type netdev receives a packet, it copies the
> packet from the NIC to a buffer in userspace. Currently, when making
> an upcall, the packet is again copied to the upcall's buffer. Howev
When a bridge of datatype type netdev receives a packet, it copies the
packet from the NIC to a buffer in userspace. Currently, when making
an upcall, the packet is again copied to the upcall's buffer. However,
this extra copy is not necessary when the datapath exists in userspace
as the upcall can
I confirm this patch fix the bug, but have a high level concern,
Assume another learnt flow with hard_timeout=10 and was never hit after
install, now, if there is frequent change to the flow table and
need_revalidate
is constantly 'true', this learnt flow will never timeout... since we
always
re
Hey Jarno,
I didn't consider that possibility, but that is a much better solution
which makes for a much cleaner patch. I just posted a new patch using this
direct pointer assignment. Looks like I'm a bit rusty on my C :P
Thanks for the review!
Ryan
On 6/3/14 10:10 AM, "Jarno Rajahalme" wrote:
On Tue, Jun 3, 2014 at 10:33 AM, Ryan Wilson wrote:
> When a bridge of datatype type netdev receives a packet, it copies the
> packet from the NIC to a buffer in userspace. Currently, when making
> an upcall, the packet is again copied to the upcall's buffer. However,
> this extra copy is not nece
I think Pravin will need to take a look in case he has something in the
pipeline that might conflict with this.
On my part:
Acked-by: Jarno Rajahalme
Jarno
On Jun 3, 2014, at 10:33 AM, Ryan Wilson wrote:
> When a bridge of datatype type netdev receives a packet, it copies the
> packet fro
Hi Ben,
thanks for the suggestion.
I’m about to send another patch that makes use of AC_LINK_IFELSE directly.
Daniele
On May 12, 2014, at 5:55 PM, Ben Pfaff wrote:
> On Mon, May 12, 2014 at 12:47:47PM -0700, Daniele Di Proietto wrote:
>> On some systems libintel_dpdk.a fails to link with libop
On some systems libintel_dpdk.a fails to link with libopenvswitch
unless -ldl is used. This should address the issue
Signed-off-by: Daniele Di Proietto
---
acinclude.m4 | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/acinclude.m4 b/acinclude.m4
On Tue, Jun 3, 2014 at 3:20 AM, maryam.tahhan wrote:
> This patch implements the vhost-net offload API. It adds support for
> a new port type to userspace datapath called dpdkvhost. This allows KVM
> (QEMU) to offload the servicing of virtio-net devices to it's associated
> dpdkvhost port. Instru
On Mon, Jun 2, 2014 at 6:37 PM, Changbin Liu wrote:
> Hi Folks,
>
> Using Open vSwitch I am setting up VXLAN tunnels between hosts. I intend to
> make VXLAN tunnels "highly available" via Keepalived. Specifically, there
> are one master node and one backup node for each host, and they share a
> Vi
[adding ovs-dev, hope that's OK]
On Tue, Jun 03, 2014 at 10:19:23AM -0700, Jarno Rajahalme wrote:
>
> On Jun 3, 2014, at 9:56 AM, Gurucharan Shetty wrote:
>
> > Hello Jarno,
> > Occasionally the cmap tests fail on Windows platform with the following o/p.
> >
> > #tests/ovstest test-cmap check
On May 22, 2014, at 10:43 AM, Ben Pfaff wrote:
> I find myself wondering whether we could end up with a funny
> paradoxical mask, e.g. mark some bit of a TCP port as looked at even
> though we didn't mark the IP protocol as looked at. I am not sure
> whether this can happen or whether this is a
Hi,
Would you be interested to acquire a list of MS HyperV-End Users & Partners
across worldwide who can be potential clients for your company?
Data fields are name, title, email, phone, address and company details,
linkedIn Url or database can be filtered based on the criteria given by the
cl
OVS is slow when compiled with pthreads atomics. Add a generic note
in INSTALL, with a reference to lib/ovs-atomic.h, where a new comment
provides additional detail.
Signed-off-by: Jarno Rajahalme
---
INSTALL |4
lib/ovs-atomic.h |3 +++
2 files changed, 7 insertions(+)
d
On Jun 2, 2014, at 8:50 PM, YAMAMOTO Takashi wrote:
>>
>> On Jun 2, 2014, at 12:51 PM, Ben Pfaff wrote:
>>
>>> On Mon, Jun 02, 2014 at 12:50:45PM -0700, Jarno Rajahalme wrote:
On Jun 2, 2014, at 11:45 AM, Ben Pfaff wrote:
> I'd really hope that any serious OVS implementa
After discussing the issue with few people,
I think we should keep the old_xcache during the full revalidation.
And in xlate_learn_action(), if may_learn is false, we should check if the
learned rule is in the old_xcache, if it is, we should copy the XC_LEARN
entry
to the new_xcache list (but we
On Tue, Jun 03, 2014 at 01:09:11PM -0700, Jarno Rajahalme wrote:
> OVS is slow when compiled with pthreads atomics. Add a generic note
> in INSTALL, with a reference to lib/ovs-atomic.h, where a new comment
> provides additional detail.
>
> Signed-off-by: Jarno Rajahalme
I think this is only li
When a bridge of datatype type netdev receives a packet, it copies the
packet from the NIC to a buffer in userspace. Currently, when making
an upcall, the packet is again copied to the upcall's buffer. However,
this extra copy is not necessary when the datapath exists in userspace
as the upcall can
On Jun 3, 2014, at 2:03 PM, Ben Pfaff wrote:
> On Tue, Jun 03, 2014 at 01:09:11PM -0700, Jarno Rajahalme wrote:
>> OVS is slow when compiled with pthreads atomics. Add a generic note
>> in INSTALL, with a reference to lib/ovs-atomic.h, where a new comment
>> provides additional detail.
>>
>> S
May be we should add a new TODO section in BUILD.Windows like:
diff --git a/BUILD.Windows b/BUILD.Windows
index ca0d252..41e6eab 100644
--- a/BUILD.Windows
+++ b/BUILD.Windows
@@ -85,3 +85,11 @@ For example,
--with-openssl="C:/OpenSSL-Win32"
* Run make for the ported executables.
+
+TODO:
+--
Hey Pravin,
Thanks for the catch here! Turns out the header is already tracked in DPDK
with rte_mbuf's buffer address - sizeof(ofpbuf). Thus, I submitted another
patch that, in free_dpdk_buf(), always gets this header and uses this to
free memory.
http://patchwork.openvswitch.org/patch/4375/
Le
This better,
Acked-by: Jarno Rajahalme
On Jun 3, 2014, at 2:20 PM, Gurucharan Shetty wrote:
> May be we should add a new TODO section in BUILD.Windows like:
>
> diff --git a/BUILD.Windows b/BUILD.Windows
> index ca0d252..41e6eab 100644
> --- a/BUILD.Windows
> +++ b/BUILD.Windows
> @@ -85,3 +8
On Tue, Jun 03, 2014 at 02:16:29PM -0700, Jarno Rajahalme wrote:
>
> On Jun 3, 2014, at 2:03 PM, Ben Pfaff wrote:
>
> > On Tue, Jun 03, 2014 at 01:09:11PM -0700, Jarno Rajahalme wrote:
> >> OVS is slow when compiled with pthreads atomics. Add a generic note
> >> in INSTALL, with a reference to
Previously, DPDK buffers were freed using 'struct ofpbuf' pointers
passed to free_dpdk_buf(). However, if a new ofpbuf allocated on the
stack shares data with the old ofpbuf and the new ofpbuf is to be
freed with free_dpdk_buf(), this will cause an error.
This patch gets the beginning of the alloc
Me too.
Acked-by: Ben Pfaff
On Tue, Jun 03, 2014 at 02:22:48PM -0700, Jarno Rajahalme wrote:
> This better,
>
> Acked-by: Jarno Rajahalme
>
> On Jun 3, 2014, at 2:20 PM, Gurucharan Shetty wrote:
>
> > May be we should add a new TODO section in BUILD.Windows like:
> >
> > diff --git a/BUIL
In case DP_HASH and RECIRC actions need to be executed in slow path,
current implementation simply don't handle them -- vswitchd simply
crashes. This patch fixes them by supply an implementation for them.
RECIRC will be handled by the datapath, same as the output action.
DP_HASH, on the other han
Ben, thanks for the review. Both are valid.
I will send out a V2 soon that should address both points.
On Thu, May 29, 2014 at 2:02 PM, Ben Pfaff wrote:
> On Wed, May 28, 2014 at 05:00:48PM -0700, Andy Zhou wrote:
>> In case DP_HASH and RECIRC actions need to be executed in slow path,
>> current
Thanks!
On Tue, Jun 03, 2014 at 02:30:12PM -0700, Andy Zhou wrote:
> Ben, thanks for the review. Both are valid.
>
> I will send out a V2 soon that should address both points.
>
> On Thu, May 29, 2014 at 2:02 PM, Ben Pfaff wrote:
> > On Wed, May 28, 2014 at 05:00:48PM -0700, Andy Zhou wrote:
>
On 4 June 2014 05:39, Alex Wang wrote:
> I confirm this patch fix the bug, but have a high level concern,
>
>
> Assume another learnt flow with hard_timeout=10 and was never hit after
> install, now, if there is frequent change to the flow table and
> need_revalidate
> is constantly 'true', this
You are right, sorry for misreading your patch.
Acked-by: Alex Wang
On Tue, Jun 3, 2014 at 2:51 PM, Joe Stringer wrote:
> On 4 June 2014 05:39, Alex Wang wrote:
>
>> I confirm this patch fix the bug, but have a high level concern,
>>
>>
>> Assume another learnt flow with hard_timeout=10 and
Acked-by: Alex Wang
On Tue, Jun 3, 2014 at 2:59 AM, Joe Stringer wrote:
> The only user of this function was removed in the previous patch, so
> remove it.
>
> Signed-off-by: Joe Stringer
> ---
> ofproto/ofproto-dpif.c | 12
> ofproto/ofproto-provider.h |2 --
> ofprot
On Wed, Jun 04, 2014 at 09:51:16AM +1200, Joe Stringer wrote:
> On 4 June 2014 05:39, Alex Wang wrote:
>
> > I confirm this patch fix the bug, but have a high level concern,
> >
> >
> > Assume another learnt flow with hard_timeout=10 and was never hit after
> > install, now, if there is frequent
Yes, I have confirmed that this patch fix the bug.
On Tue, Jun 3, 2014 at 3:11 PM, Ben Pfaff wrote:
> On Wed, Jun 04, 2014 at 09:51:16AM +1200, Joe Stringer wrote:
> > On 4 June 2014 05:39, Alex Wang wrote:
> >
> > > I confirm this patch fix the bug, but have a high level concern,
> > >
> > >
I'm not against this idea; It seems correct to me, to keep the cache the
same even if we need to revalidate, because we will throw it away if
revalidation fails anyway.
We already had a discussion about using the xcache even when revalidation
is required:-
http://openvswitch.org/pipermail/dev/2014
OK.
My memory consumption comment is just quibbling. I'd like to get in
the fix, then we can reduce the memory consumption if need be.
On Tue, Jun 03, 2014 at 03:14:01PM -0700, Alex Wang wrote:
> Yes, I have confirmed that this patch fix the bug.
>
>
> On Tue, Jun 3, 2014 at 3:11 PM, Ben Pfaff
Would this incremental alleviate your concerns?
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index e8f3dbf..aa8cea1 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -3000,11 +3000,11 @@ xlate_learn_action(struct xlate_ctx *ctx, const
struc
On Wed, Jun 04, 2014 at 10:30:13AM +1200, Joe Stringer wrote:
> Would this incremental alleviate your concerns?
>
> diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
> index e8f3dbf..aa8cea1 100644
> --- a/ofproto/ofproto-dpif-xlate.c
> +++ b/ofproto/ofproto-dpif-xlate.c
> @
OK, thanks. I'll push this patchset to master and branch-2.3 soon.
On 4 June 2014 10:33, Ben Pfaff wrote:
> On Wed, Jun 04, 2014 at 10:30:13AM +1200, Joe Stringer wrote:
> > Would this incremental alleviate your concerns?
> >
> > diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-
Thank you! Also many thanks to Alex.
On Wed, Jun 04, 2014 at 10:34:44AM +1200, Joe Stringer wrote:
> OK, thanks. I'll push this patchset to master and branch-2.3 soon.
>
>
> On 4 June 2014 10:33, Ben Pfaff wrote:
>
> > On Wed, Jun 04, 2014 at 10:30:13AM +1200, Joe Stringer wrote:
> > > Would
On Mon, Jun 2, 2014 at 9:04 PM, Simon Horman wrote:
> Hi Jesse,
>
> thanks for your feedback.
>
> On Mon, Jun 02, 2014 at 05:58:10PM -0700, Jesse Gross wrote:
>> On Sun, May 25, 2014 at 5:22 PM, Simon Horman wrote:
>> > diff --git a/datapath/flow_netlink.c b/datapath/flow_netlink.c
>> > index 803
Yes, Alex has helped a lot with this. Thanks Alex!
On 4 June 2014 10:36, Ben Pfaff wrote:
> Thank you! Also many thanks to Alex.
>
> On Wed, Jun 04, 2014 at 10:34:44AM +1200, Joe Stringer wrote:
> > OK, thanks. I'll push this patchset to master and branch-2.3 soon.
> >
> >
> > On 4 June 2014
Thanks, I pushed this series to master and branch-2.3.
On 4 June 2014 10:06, Alex Wang wrote:
> Acked-by: Alex Wang
>
>
> On Tue, Jun 3, 2014 at 2:59 AM, Joe Stringer
> wrote:
>
>> The only user of this function was removed in the previous patch, so
>> remove it.
>>
>> Signed-off-by: Joe Stri
I've ran into some unexpected issues while perf testing this, lets hold
off on looking at this. I'll submit another patch when I've had all the
kinks worked out.
Ryan
On 6/3/14 2:21 PM, "Ryan Wilson 76511" wrote:
>Hey Pravin,
>
>Thanks for the catch here! Turns out the header is already tracked
If an MPLS packet requires segmentation then use mpls_features
to determine if the software implementation should be used.
As no driver advertises MPLS GSO segmentation this will always be
the case.
I had not noticed that this was necessary before as software MPLS GSO
segmentation was already bei
Hi Pravin,
On May 30, 2014, at 4:53 PM, Pravin Shelar wrote:
> We just need to reset mf->map, Can you add api for that ?
> infact miniflow_extract() does not read from map, is there need to
> initialize it on every packet?
You’re right. mini flow_extract() should be enough.
> This metadata is sa
On Tue, Jun 3, 2014 at 2:51 AM, Wenyu Zhang wrote:
>
> I am trying to simulate traffic in test cases to test IPFIX feature.
>
> For normal traffic, I can use "ovs-appctl netdev-dummy/receive " to simulate
> it, just refer to the netflow and sflow cases in tests/ofproto-dpif.at
> And I can capture
On May 30, 2014, at 4:54 PM, Pravin Shelar wrote:
> On Fri, May 23, 2014 at 11:04 AM, Daniele Di Proietto
> wrote:
> need to skip this packet.
Ops, added a continue.
>>
>> +/* TODO: warn if any packet bigger than dev->max_packet_len */
>
> I think we have to check this. Better to ad
On May 30, 2014, at 4:55 PM, Pravin Shelar wrote:
>>
>> int i;
>>
>> +memset(&batch, 0, sizeof batch);
>> +
> Is there need to reset batch? can batch_init() take care of it?
You’re right. It should be enough to set batch.flow to NULL.
>
>> +for (i = 0; i < c; i++) {
>> +
The netdev_send function has been modified to accept multiple packets, to
allow netdev providers to amortize locking and queuing costs.
This is especially true for netdev-dpdk.
Later commits exploit the new API.
Signed-off-by: Daniele Di Proietto
---
lib/dpif-netdev.c | 2 +-
lib/netdev-b
As per netdev-provider interface, netdev_dpdk_rxq_recv should receive at most
NETDEV_MAX_RX_BATCH.
Signed-off-by: Daniele Di Proietto
---
lib/netdev-dpdk.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index ba41d2e..7a78c34 100644
-
This change in dpif-netdev allows faster packet processing for devices which
implement batching (netdev-dpdk currently).
Signed-off-by: Daniele Di Proietto
---
lib/dpif-netdev.c| 240 ++-
lib/dpif.c | 7 +-
lib/odp-execute.c
Can you combine it with second patch, otherwise it introduces a bug.
On Tue, Jun 3, 2014 at 4:22 PM, Ryan Wilson 76511 wrote:
> I've ran into some unexpected issues while perf testing this, lets hold
> off on looking at this. I'll submit another patch when I've had all the
> kinks worked out.
>
>
I agree, that would look a bit tidier. I'll send a patch.
On 3 June 2014 08:53, Ethan Jackson wrote:
> I'm wondering if it'd be cleaner to have ukey_create() return a locked
> ukey, and to pull the try_lock() into the critical section for the
> ukeys map? I.E.
>
> lock_hmap()
> ukey = ukey_loo
Signed-off-by: Joe Stringer
---
v3: Don't require users to specify "-k" for searches.
v2: No change.
v1: First post.
---
utilities/ovs-dev.py | 14 ++
1 file changed, 14 insertions(+)
diff --git a/utilities/ovs-dev.py b/utilities/ovs-dev.py
index 814a9d0..2c3af19 100755
--- a/utili
Signed-off-by: Joe Stringer
---
v3: Set the default to -j8.
v2: Make it configurable.
v1: First post.
---
utilities/ovs-dev.py |6 ++
1 file changed, 6 insertions(+)
diff --git a/utilities/ovs-dev.py b/utilities/ovs-dev.py
index 2c3af19..fa74d57 100755
--- a/utilities/ovs-dev.py
+++ b/ut
Acked-by: Ethan Jackson
On Tue, Jun 3, 2014 at 5:41 PM, Joe Stringer wrote:
> Signed-off-by: Joe Stringer
> ---
> v3: Don't require users to specify "-k" for searches.
> v2: No change.
> v1: First post.
> ---
> utilities/ovs-dev.py | 14 ++
> 1 file changed, 14 insertions(+)
>
>
Sorry to nit pick, but could we change the option name to "--jobs" and
the abbreviated option to "-j". This is consistent with how make does
it.
Acked-by: Ethan Jackson
On Tue, Jun 3, 2014 at 5:41 PM, Joe Stringer wrote:
> Signed-off-by: Joe Stringer
> ---
> v3: Set the default to -j8.
> v2:
On Tue, Jun 03, 2014 at 03:40:27PM -0700, Jesse Gross wrote:
> On Mon, Jun 2, 2014 at 9:04 PM, Simon Horman wrote:
> > Hi Jesse,
> >
> > thanks for your feedback.
> >
> > On Mon, Jun 02, 2014 at 05:58:10PM -0700, Jesse Gross wrote:
> >> On Sun, May 25, 2014 at 5:22 PM, Simon Horman wrote:
> >> >
Couple of questions.
First, this patch adds a bit of code which extends beyond 79 characters.
dp_netdev_input() does this rather interesting stuff with two keys
that mfk switches between. This is definitely not obvious when first
looking at it. Minimally it needs a comment explaining why. That
When a bridge of datatype type netdev receives a packet, it copies the
packet from the NIC to a buffer in userspace. Currently, when making
an upcall, the packet is again copied to the upcall's buffer. However,
this extra copy is not necessary when the datapath exists in userspace
as the upcall can
Oh, also I'm getting these errors when compiling with clang's thread
saftey analysis.
../lib/dpif-netdev.c:2115:12: error: reading variable 'head' requires
locking any mutex [-Werror,-Wthread-safety-analysis]
if (q->head - q->tail < MAX_QUEUE_LEN) {
^
../lib/dpif-netdev.c:2115:22: e
Sure, I combined them and sent out a new patch fixing all the bugs I
encountered in the DPDK perf test.
http://patchwork.openvswitch.org/patch/4388/
One issue is that since ofproto-dpif-upcall calls ofpbuf_uninit(), I had
to free the DPDK buffer in that function as opposed to ofpbuf_delete().
I'
> On Jun 3, 2014, at 6:11 PM, Ryan Wilson wrote:
>
> When a bridge of datatype type netdev receives a packet, it copies the
> packet from the NIC to a buffer in userspace. Currently, when making
> an upcall, the packet is again copied to the upcall's buffer. However,
> this extra copy is not nec
> On Jun 3, 2014, at 6:22 PM, Ryan Wilson 76511 wrote:
>
> Sure, I combined them and sent out a new patch fixing all the bugs I
> encountered in the DPDK perf test.
>
> http://patchwork.openvswitch.org/patch/4388/
>
>
> One issue is that since ofproto-dpif-upcall calls ofpbuf_uninit(), I had
One of the reasons that xlate_cache was introduced was to ensure that
statistics were attributed to the correct rules and interfaces according
to the flow that was installed into the datapath, rather than according
to the current state of the flow table.
This patch makes the revalidators use the x
This patch refactors the code around ukey creation and lookup to
simplify the code for callers. A new function ukey_acquire() combines
these functions and attempts to acquire a lock on the ukey. Failure to
acquire a lock on the ukey is usually a sign that another thread is
handling the same flow co
Rather than setting and resetting the 'mark' field in the ukey, this
patch introduces a seq to track whether a flow has been seen during the
most recent dump. This tidies the code and simplifies the logic for
detecting when flows are duplicated from the datapath.
Signed-off-by: Joe Stringer
---
v
Thanks, I applied this with the following incremental:
diff --git a/utilities/ovs-dev.py b/utilities/ovs-dev.py
index fa74d57..efc65c8 100755
--- a/utilities/ovs-dev.py
+++ b/utilities/ovs-dev.py
@@ -145,8 +145,8 @@ commands.append(make)
def check():
flags = ""
-if options.parallel:
-
Thanks Pravin, I applied this to master.
On 31 May 2014 07:33, Pravin Shelar wrote:
> On Mon, May 26, 2014 at 6:47 PM, Joe Stringer
> wrote:
> > This was causing failures in 'make distcleancheck'.
> >
> > Signed-off-by: Joe Stringer
>
> LGTM
> Acked-by: Pravin B Shelar
>
> > ---
> > datapat
Thanks, pushed to master.
On 4 June 2014 12:44, Ethan Jackson wrote:
> Acked-by: Ethan Jackson
>
>
> On Tue, Jun 3, 2014 at 5:41 PM, Joe Stringer
> wrote:
> > Signed-off-by: Joe Stringer
> > ---
> > v3: Don't require users to specify "-k" for searches.
> > v2: No change.
> > v1: First post.
> This patch also checks the system platform as clock_gettime
> could exist on different platforms but with different values of
> CLOCK_MONOTONIC and different definitions of 'struct timespec'.
> In this case, the system call would be expected to catch the
> error, which is dangerous.
>
> This pat
> Thanks for the fix! Sorry, I don't know too much about the intricacies of
> NetBSD. My first version seemed to work on my NetBSD instance though, so I
> wrongly assumed it would work for most versions of NetBSD.
it picked the old (pre-64bit-time_t) compat version of the function.
yes, it should
It's unclear why these tests are named "ofproto-if..." unlike all of the
other ofproto-dpif tests. Rename them to be more consistent.
Signed-off-by: Joe Stringer
---
tests/ofproto-dpif.at |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/ofproto-dpif.at b/tests
Thanks for your help.
And how about "ovs-appctl ofproto/trace ovs-dummy" command? The manual about
ovs-vswitchd says that it can generate a packet with "-generate" option.
Can it fit my requirement?
Bests,
Wenyu
- Original Message -
From: "Jesse Gross"
To: "Wenyu Zhang"
Cc: dev@openvsw
On Wed, Jun 04, 2014 at 02:54:27PM +1200, Joe Stringer wrote:
> It's unclear why these tests are named "ofproto-if..." unlike all of the
> other ofproto-dpif tests. Rename them to be more consistent.
>
> Signed-off-by: Joe Stringer
Acked-by: Simon Horman
> ---
> tests/ofproto-dpif.at |8 +
Thanks, Jesse.
I figured out the issue. For those who are interested in using VIP as VXLAN
endpoint IP: after the backup node takes over VIP, its "source address"
also needs to be updated. By default (I tested with Ubuntu 14.04 OS), the
bakcup node's source address keeps unchanged. That explains
2014-06-04 8:12 GMT+04:00 Changbin Liu :
> I figured out the issue. For those who are interested in using VIP as VXLAN
> endpoint IP: after the backup node takes over VIP, its "source address" also
> needs to be updated. By default (I tested with Ubuntu 14.04 OS), the bakcup
> node's source addres
It appears that we can change source address via updating the routing table.
http://www.symantec.com/business/support/index?page=content&id=HOWTO58872
But somehow it doesn't work on Ubuntu 14.04. Maybe I missed something.
So right now, manually I first delete the default IP on the interface, and
On some platforms including NetBSD,
GNU make is usually installed as "gmake".
Signed-off-by: YAMAMOTO Takashi
---
tutorial/automake.mk | 2 +-
tutorial/ovs-sandbox | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tutorial/automake.mk b/tutorial/automake.mk
index d88d5b4..82
> In case DP_HASH and RECIRC actions need to be executed in slow path,
> current implementation simply don't handle them -- vswitchd simply
> crashes. This patch fixes them by supply an implementation for them.
>
> RECIRC will be handled by the datapath, same as the output action.
>
> DP_HASH, on
Acked-by: YAMAMOTO Takashi
> Me too.
>
> Acked-by: Ben Pfaff
>
>
> On Tue, Jun 03, 2014 at 02:22:48PM -0700, Jarno Rajahalme wrote:
>> This better,
>>
>> Acked-by: Jarno Rajahalme
>>
>> On Jun 3, 2014, at 2:20 PM, Gurucharan Shetty wrote:
>>
>> > May be we should add a new TODO section i
> OVS is slow when compiled with pthreads atomics. Add a generic note
> in INSTALL, with a reference to lib/ovs-atomic.h, where a new comment
> provides additional detail.
>
> Signed-off-by: Jarno Rajahalme
Acked-by: YAMAMOTO Takashi
> ---
> INSTALL |4
> lib/ovs-atomic.h |
86 matches
Mail list logo
