Hey Justin,
Thx for the responsive review~
On Wed, Aug 12, 2015 at 11:58 PM, Justin Pettit wrote:
> I should have added that if you use the attached patch, you'll need to
> update the ovn-sbctl unit test you were nice enough to include in this
> patch.
>
> --Justin
>
>
> > On Aug 12, 2015, at 1
There is a miss-match between the handling of invalid ICMPv6 fields in the
implementations of parse_icmpv6() in user-space and in the kernel datapath.
This patch addresses that by modifying the user-space implementation to
match that of the kernel datapath; processing is terminated without
rather
Adopted all suggestions and fixed unittest,
Applied to master~
Thanks,
Alex Wang,
On Thu, Aug 13, 2015 at 12:17 AM, Alex Wang wrote:
> Hey Justin,
>
> Thx for the responsive review~
>
> On Wed, Aug 12, 2015 at 11:58 PM, Justin Pettit
> wrote:
>
>> I should have added that if you use the attac
Awesome! I tested it, and it looks good. Thanks so much.
--Justin
> On Aug 13, 2015, at 12:55 AM, Alex Wang wrote:
>
> Adopted all suggestions and fixed unittest,
>
> Applied to master~
>
> Thanks,
> Alex Wang,
>
> On Thu, Aug 13, 2015 at 12:17 AM, Alex Wang wrote:
> Hey Justin,
>
> Thx
Alex,
I have lost at least 32 packets while testing this patch yesterday(~15
configuration changes).
Is it bad? What is worse: loosing of ~1-2 bursts of packets or a little stats
about threads?
Best regards, Ilya Maximets.
On 12.08.2015 23:09, Alex Wang wrote:
>
>
> On Wed, Aug 12, 2015 at 1:
Hi All,
I want to apply rate limiting on unknown unicast packet. When destination
address is not found in the mac table flooding will occurs in ovs. Can we apply
any policy/rule to rate limit the traffic for unknown packet/traffic.
Thanks & Regards,
Abhishek
The information contained in this el
ping.
On 06.08.2015 17:32, Ilya Maximets wrote:
> Currently tx_qid is equal to pmd->core_id. This leads to unexpected
> behavior if pmd-cpu-mask different from '/(0*)(1|3|7)?(f*)/',
> e.g. if core_ids are not sequential, or doesn't start from 0, or both.
>
> Example:
> starting 2 pmd thread
Ok, thanks for explanation.
In that case, I think, try-lock solution will be good.
Best regards, Ilya Maximets.
On 12.08.2015 23:52, Alex Wang wrote:
> Hey Ilya,
>
> Thanks for the reply please see my comments inline,
>
> Thanks,
> Alex Wang,
>
> On Wed, Aug 12, 2015 at 4:19 AM, Ilya Maximets
Acked-by: Jarno Rajahalme
Jarno
> On Aug 12, 2015, at 6:14 PM, Ethan J. Jackson wrote:
>
> From: Ethan Jackson
>
> Future patches will need to modify ukey actions in some instances.
> This patch makes this possible by protecting them with RCU. It also
> adds thread safety checks to enforc
Some older distros might not define _rundir yet so in this
case the RPM build breaks. This patch defines it to the
Fedora's default.
Signed-off-by: Flavio Leitner
---
rhel/openvswitch-fedora.spec.in | 6 ++
1 file changed, 6 insertions(+)
diff --git a/rhel/openvswitch-fedora.spec.in b/rhel
For performance-critical threads like pmd threads, we currently make them
never call coverage_clear() to avoid contention over the global mutex
'coverage_mutex'. So, even though pmd thread still keeps updating their
thread-local coverage count, the count is never attributed to the global
total. B
On Thu, Aug 13, 2015 at 8:26 AM, Ilya Maximets
wrote:
> Ok, thanks for explanation.
> In that case, I think, try-lock solution will be good.
>
> Best regards, Ilya Maximets.
>
Thx Ilya, for the suggestions and discussion
I posted a patch here:
http://openvswitch.org/pipermail/dev/2015-August/
This patch adds the following to OVN %files:
/usr/bin/ovn-controller-vtep
/usr/bin/ovn-sbctl
/usr/share/man/man8/ovn-controller-vtep.8.gz
/usr/share/man/man8/ovn-sbctl.8.gz
Signed-off-by: Flavio Leitner
---
rhel/openvswitch-fedora.spec.in | 4
1 file changed, 4 insertions(+)
di
On Thu, Aug 13, 2015 at 12:55 AM, Simon Horman
wrote:
> There is a miss-match between the handling of invalid ICMPv6 fields in the
> implementations of parse_icmpv6() in user-space and in the kernel datapath.
>
> This patch addresses that by modifying the user-space implementation to
> match that
From: mengke
In the test the bridge is configured with type "netdev" and the VXLAN port is
configured with "options: remote_ip=flow options: key=flow", the VXLAN packets
can't be matched for the rule (ovs-ofctl add-flow br-int
"priority=200,in_port=2,tun_src=200.2.0.101, ip, actions= drop").
On Thu, Aug 13, 2015 at 6:19 PM, Mengke wrote:
> From: mengke
>
> In the test the bridge is configured with type "netdev" and the VXLAN port is
> configured with "options: remote_ip=flow options: key=flow", the VXLAN
> packets can't be matched for the rule (ovs-ofctl add-flow br-int
> "priorit
OK , Thanks.
-Original Message-
From: Jesse Gross [mailto:je...@nicira.com]
Sent: Friday, August 14, 2015 9:17 AM
To: Liu, Mengke
Cc: dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH] fix match issue for decap when the
remote_ip=flow in userspace implementation
On Thu, Aug 13, 2015 at
When an error occurs skipping IPv6 extension headers retain the already
parsed IP protocol and IPv6 addresses in the flow. Also assume that the
packet is not a fragment in the absence of information to the contrary;
that is always use the frag_off value set by ipv6_skip_exthdr().
This allows match
Whenever we write into a tunnel option field, we also need to mark
it as significant. If we don't, then the data will later be ignored.
We currently do this in every case except for flow metadata. This causes
us to not correctly serialize the tunnel metadata for Packet Ins to the
controller.
Rath
19 matches
Mail list logo
