Could you tell me why I am wrong?
At 2015-09-11 11:08:29, "Ben Pfaff" wrote:
>On Fri, Sep 11, 2015 at 09:52:19AM +0800, openvswitcher wrote:
>> >When the datapath flow is deleted, the next packet will cause a
>> >flow-miss, which will cause a corrected flow to be inserted.
>>
>> But the d
On Fri, Sep 11, 2015 at 09:52:19AM +0800, openvswitcher wrote:
> >When the datapath flow is deleted, the next packet will cause a
> >flow-miss, which will cause a corrected flow to be inserted.
>
> But the datapath flow will be deleted when the kernel-flow timeout.
> The packet will not be correct
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On 9/10/15 2:54 PM, Ben Pfaff wrote:
diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
+80:fa:5b:06:72:b7 192.168.1.10/24
IPv6 too ? :)
+
+ This adds further restrictions to the first example. The host may
+ send IPv4 packets from or receive IPv4 packets to on
> On Sep 9, 2015, at 7:00 PM, Joe Stringer wrote:
>
>
(snip)
> diff --git a/datapath/linux/compat/include/linux/openvswitch.h
> b/datapath/linux/compat/include/linux/openvswitch.h
> index 578cd88..69bdf32 100644
> --- a/datapath/linux/compat/include/linux/openvswitch.h
> +++ b/datapath/linux
>When the datapath flow is deleted, the next packet will cause a
>flow-miss, which will cause a corrected flow to be inserted.
But the datapath flow will be deleted when the kernel-flow timeout.
The packet will not be correct before timeout. Won't it?
At 2015-09-11 01:02:25, "Ben Pfaff" w
Rather than describing this intention after the fact, encode this
meaning in the name of a function.
Signed-off-by: Joe Stringer
---
ofproto/ofproto-dpif-ipfix.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/ofproto/ofproto-dpif-ipfix.c b/ofproto/ofproto-dpif-ipf
A divide-by-zero exception like the below could occur when IPFIX
configuration is cleared while handling sampled packets from the
datapath. While it's not valid to configure the sampling probability of
IPFIX to zero via explicitly setting it in OVSDB, it is possible to
clear the configuration, whic
Previously, we had no IPFIX tests in the testsuite. Now we have one.
Signed-off-by: Joe Stringer
---
tests/ofproto-dpif.at | 37 +
1 file changed, 37 insertions(+)
diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
index eb8647b..93ce5df 100644
--- a/
Primarily this series is attempting to address a divide-by-zero error in
the bridge sampling code for IPFIX, but a couple of other minor changes
leaked in too. Unfortunately I haven't been able to reproduce this issue
locally in the testsuite. Full description below, also available in the
commit me
Currently when running the vswitch daemon we get a lot of messages of the
form:
2015-09-10T23:04:21Z|07255|dpif(revalidator11)|WARN|system@ovs-system: failed
to flow_del (Invalid argument).
The userspace expects after sending a delete flow command, to receive the flow
key of the deleted flow.
Cur
> On Sep 10, 2015, at 3:23 PM, Joe Stringer wrote:
>
> On 10 September 2015 at 11:05, Ben Pfaff wrote:
>> Who do you think should review this?
>
> I think that either Justin or Jarno should probably review this.
I’ll review these, but Justin can chime in as well :-)
Jarno
On 10 September 2015 at 11:05, Ben Pfaff wrote:
> Who do you think should review this?
I think that either Justin or Jarno should probably review this.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
One point that I would like to bring to attention is that vtep-ctl no
longer matches VTEP schema (even without this patch).
On Thu, Sep 10, 2015 at 3:07 PM, Justin Pettit wrote:
>
>> On Aug 25, 2015, at 1:03 PM, Bruce Davie wrote:
>>
>> diff --git a/vtep/vtep.xml b/vtep/vtep.xml
>> index ff8d0fe
If we have a flow rule of the following form:
actions=strip_vlan,set_tunnel:0x3e9,15,16,17 (Where port 15, 16 and 17 are
VXLAN OF ports with different tunnelling information)
Current implementation is that if a packet will hit that specific flow,
only one packet will be sent out with the first t
> On Aug 25, 2015, at 1:03 PM, Bruce Davie wrote:
>
> diff --git a/vtep/vtep.xml b/vtep/vtep.xml
> index ff8d0fe..a554dcf 100644
> --- a/vtep/vtep.xml
> +++ b/vtep/vtep.xml
> @@ -367,7 +367,7 @@
>
>
> The HSC writes the key-value pairs in the
> - column to spe
Acked-by: Jarno Rajahalme
> On Sep 10, 2015, at 1:18 PM, Ben Pfaff wrote:
>
> It seems to me that a controller bug doesn't rise to the level of a WARN
> that causes a testsuite failure (by default).
>
> Signed-off-by: Ben Pfaff
> ---
> ofproto/ofproto.c | 4 ++--
> 1 file changed, 2 insertions
> On Sep 10, 2015, at 2:30 PM, Ben Pfaff wrote:
>
> On Thu, Sep 10, 2015 at 02:07:22PM -0700, Justin Pettit wrote:
>>
>>> On Sep 5, 2015, at 4:40 PM, Ben Pfaff wrote:
>>>
>>> On Fri, Sep 04, 2015 at 05:39:01PM -0700, Justin Pettit wrote:
Introduce a new "direction" column to the ACL tabl
On Thu, Sep 10, 2015 at 02:07:54PM -0700, Justin Pettit wrote:
>
> > On Sep 5, 2015, at 4:53 PM, Ben Pfaff wrote:
> >
> > -printf("%10s %5ld (%s) %s%s\n", acl->direction, acl->priority,
> > +printf("%10s %5"PRId64" (%s) %s%s\n", acl->direction,
> > acl->priority,
>
> Fixed.
>
On Thu, Sep 10, 2015 at 02:07:22PM -0700, Justin Pettit wrote:
>
> > On Sep 5, 2015, at 4:40 PM, Ben Pfaff wrote:
> >
> > On Fri, Sep 04, 2015 at 05:39:01PM -0700, Justin Pettit wrote:
> >> Introduce a new "direction" column to the ACL table that accepts the
> >> values "to-lport" and "from-lpor
> On Sep 5, 2015, at 4:53 PM, Ben Pfaff wrote:
>
> -printf("%10s %5ld (%s) %s%s\n", acl->direction, acl->priority,
> +printf("%10s %5"PRId64" (%s) %s%s\n", acl->direction, acl->priority,
Fixed.
> I'd prefer to avoid casts in acl_cmp(), also the macro there doesn't
> seem to hel
> On Sep 5, 2015, at 4:40 PM, Ben Pfaff wrote:
>
> On Fri, Sep 04, 2015 at 05:39:01PM -0700, Justin Pettit wrote:
>> Introduce a new "direction" column to the ACL table that accepts the
>> values "to-lport" and "from-lport". Also reserve the ACL priority 65535
>> for return traffic associated w
It seems to me that a controller bug doesn't rise to the level of a WARN
that causes a testsuite failure (by default).
Signed-off-by: Ben Pfaff
---
ofproto/ofproto.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index c1301b5..c7dd8
Otherwise duplicate bucket IDs cause linked list loops and other nastiness
because the ofputil_bucket_find() in the OFPG15_BUCKET_LAST case later in
copy_buckets_for_insert_bucket() will find the new bucket instead of the
old one and the list_splice() call becomes nonsensical.
Reported-by: Ray Li
On Thu, Sep 10, 2015 at 10:02 AM, Daniele Di Proietto
wrote:
> DPDK mbufs contain a valid RSS hash only if PKT_RX_RSS_HASH is
> set in 'ol_flags'. Otherwise the hash is garbage and doesn't
> relate to the packet.
>
> This fixes an issue with vhost, which, being a virtual NIC, doesn't
> compute th
I posted a patch (it still is just a proposal, no code):
http://openvswitch.org/pipermail/dev/2015-September/059861.html
On Wed, Sep 09, 2015 at 06:51:05PM -0700, Ben Pfaff wrote:
> On Wed, Sep 09, 2015 at 06:23:13PM -0700, Justin Pettit wrote:
> > > This column is provided as
The "obvious" implementation of port security based on this proposal
would be a single long match expression. For example, suppose that
the port_security expression is "00:00:00:00:00:01 192.168.0.1".
Then one might naturally write:
eth.src == 00:00:00:00:00:01
&& (!arp || (arp
On Wed, Sep 09, 2015 at 07:12:20PM -0700, Joe Stringer wrote:
> On 9 September 2015 at 19:00, Joe Stringer wrote:
>
> >
> > This series is also available as a pull request, here:
> > https://github.com/openvswitch/ovs/pull/66
>
> My mail client ate patches 4 and 6, due to this one line that's ov
Who do you think should review this?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Sorry for the delay.
There's still one problem with this patch:
when a non-DPDK port is added to the datapath, its txqs are not
added to the pmd threads.
Can you confirm the issue?
Thanks
On 10/09/2015 07:52, "Ilya Maximets" wrote:
>Ping.
>
>On 02.09.2015 14:44, Ilya Maximets wrote:
>> Curre
On Wed, Sep 09, 2015 at 07:00:18PM -0700, Joe Stringer wrote:
> The next patch will introduce nested actions with special restrictions.
> Refactor the action verification to allow ofpacts_verify() to identify
> nesting so that these retrictions may be applied.
s/retrictions/restrictions/
Here's a
Hi,
Did you get a chance to review my previous email?
Please let me know your target audience so that I can get back to you with
more relevant information.
Best Regards
Elina Roberts
From: Elina Roberts [mailto:elina.robe...@emaildatamarket.com]
Sent: Thursday, September 03, 2015 2:
On Wed, Sep 09, 2015 at 07:00:17PM -0700, Joe Stringer wrote:
> This combines a common set of operations into a single command.
>
> Signed-off-by: Joe Stringer
Nice cleanup.
Acked-by: Ben Pfaff
___
dev mailing list
dev@openvswitch.org
http://openvswi
On 09/09/2015 18:56, "Pravin Shelar" wrote:
>On Wed, Sep 9, 2015 at 8:45 AM, Daniele Di Proietto
> wrote:
>> DPDK mbufs contain a valid RSS hash only if PKT_RX_RSS_HASH is
>> set in 'ol_flags'. Otherwise the hash is garbage and doesn't
>> relate to the packet.
>>
>> This fixes an issue with vh
DPDK mbufs contain a valid RSS hash only if PKT_RX_RSS_HASH is
set in 'ol_flags'. Otherwise the hash is garbage and doesn't
relate to the packet.
This fixes an issue with vhost, which, being a virtual NIC, doesn't
compute the hash.
Reported-by: Dongjun
Suggested-by: Flavio Leitner
Acked-by: Ke
On Thu, Sep 10, 2015 at 11:41:43AM +0800, openvswitcher wrote:
> >If the OpenFlow table changes, the kernel flow cache has to be
> >reexamined and sometimes updated.
>
> You mean the revalidate thread ? I read the source and I thought the thread
> would only delete the flow in kernel
> when the t
'bands' should be paired with 'meter_mod' because 'bands' may hold the
storage for the meter's bands. ('bands' has nothing to do with
'group_mod'.)
Reported-by: niti Rohilla
Reported-at: http://openvswitch.org/pipermail/dev/2015-September/059847.html
Signed-off-by: Ben Pfaff
---
lib/ofp-util.h
On Thu, Sep 10, 2015 at 11:50:37AM +0530, niti Rohilla wrote:
> Thanks for the review. Yes, I find this approach better where data is
> decoded only once.
>
> I have a doubt regarding the following structure:
>
> struct ofputil_requestforward {
> ovs_be32 xid;
> enum ofp14_requestforward_
Andy Zhou wrote on 09/09/2015 08:08:36 PM:
> On Wed, Sep 9, 2015 at 3:24 AM, Liran Schour wrote:
> > Andy Zhou wrote on 08/09/2015 10:42:26 PM:
> >
> >> From: Andy Zhou
> >> To: Liran Schour/Haifa/IBM@IBMIL
> >> Cc: Ben Pfaff , dev
> >> Date: 08/09/2015 10:42 PM
> >> Subject: Re: [ovs-dev] OV
39 matches
Mail list logo
