Hi,
Could someone take a look at this patch? We hit this issue (drops) on a
customer setup and appreciate your comments/suggestions.
Thanx
Manu
On 17/05/18, 3:29 PM, "ovs-dev-boun...@openvswitch.org on behalf of Manohar
Krishnappa Chidambaraswamy" wrote:
2/2: Fix packet dro
Hi,
Could someone take a look at this patch? We hit this issue (drops) on a
customer setup and appreciate your comments/suggestions.
Thanx
Manu
On 17/05/18, 3:26 PM, "ovs-dev-boun...@openvswitch.org on behalf of Manohar
Krishnappa Chidambaraswamy" wrote:
1/2: Fix packet dro
Aaron,
Thanx for your comments/suggestions. Please see inline.
Thanx
Manu
On 07/06/18, 7:06 PM, "Aaron Conole" wrote:
Manohar Krishnappa Chidambaraswamy
writes:
> Jan,
>
> Have addressed your comments/suggestions. Please take a look and let me
Thanx Ben. Will rebase and send v2 diffs.
Thanx
Manu
On 15/06/18, 2:24 AM, "Ben Pfaff" wrote:
Thanks for the patch.
The patch cannot be applied. It appears to be white space damaged.
Please resubmit using "git send-email".
___
Ben,
Here are the v2 diffs. Hope this applies without any issue.
Thanx
Manu
Signed-off-by: Manohar K C
CC: Jan Scheurich
CC: Nitin Katiyar
---
v1 1/2: https://patchwork.ozlabs.org/patch/915285/
v2 1/2: Rebased to master
lib/lacp.c | 14 --
lib/lacp.h
Hi
Problem:
In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
(using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
"HASH" and "RECIRC" datapath actions. After recirculation, the packet is
forwarded to the bond member port based on 8-bits of t
Hi Ilya,
Thanx for taking a look. Please see inline.
Thanx
Manu
On 18/06/18, 4:04 PM, "Ilya Maximets" wrote:
> Hi
Hi,
I just wanted to clarify few things about RSS hash. See inline.
One more thing:
Despite of usual OVS bonding, this implementation doesn't support
Hi Ben,
Does this patch apply without issues?
Would you be able to look at 2/2 of this series as well?
Thanx
Manu
On 18/06/18, 2:05 PM, "ovs-dev-boun...@openvswitch.org on behalf of Manohar
Krishnappa Chidambaraswamy" wrote:
Ben,
Here are the v2 diffs. Hope th
...@noironetworks.com
-Manohar Krishnappa Chidambaraswamy
manohar.krishnappa.chidambarasw...@ericsson.com
+Manohar K Cman...@gmail.com
Marcin Mirecki mmire...@redhat.com
Mario Cabrera mario.cabr...@hpe.com
Mark D. Gray mark.d.g
In OVS-DPDK, both fast-path and slow-path execute in the context of a common
thread (i.e, PMD thread), without any partitioning of CPU cycles between the
two. When there is a burst of new flows coming into the data-path, packets
are punted to slow-path in the order they are received and the PMD is
Hi,
Does anyone have any comments on this add-on to upcalls?
Thanx
Manu
On 10/11/17, 7:06 PM, "ovs-dev-boun...@openvswitch.org on behalf of Manohar
Krishnappa Chidambaraswamy" wrote:
In OVS-DPDK, both fast-path and slow-path execute in the context of a common
thread (i.e,
Hi,
2nd attempt. Does anyone have any comments on this add-on to upcalls?
Thanx
Manu
On 17/11/17, 11:17 AM, "Manohar Krishnappa Chidambaraswamy"
wrote:
Hi,
Does anyone have any comments on this add-on to upcalls?
Thanx
Manu
On 10/11/17, 7:06 PM
case, could someone please review the patch?
Thanx
Manu
On 17/11/17, 11:17 AM, "Manohar Krishnappa Chidambaraswamy"
wrote:
Hi,
Does anyone have any comments on this add-on to upcalls?
Thanx
Manu
On 10/11/17, 7:0
Rebased to master.
Could you please review this patch?
v1 of this patch has been sitting idle for quite sometime. I believe this
feature is important. Without this feature, an attacker sending packets
belonging to different (unestablished) flows can result in PMDs running only
upcalls, reducing
oken-bucket. I don’t
know much about meters. Will check.
Thanx
Manu
On Mon, Jan 15, 2018 at 08:33:31AM +0000, Manohar Krishnappa
Chidambaraswamy wrote:
> Rebased to master.
>
> Could you please review this patch?
>
> v1 of this patch has been sitting
slow-path before
meter-action can be executed.
Thanx
Manu
On 25/01/18, 11:52 AM, "ovs-dev-boun...@openvswitch.org on behalf of Manohar
Krishnappa Chidambaraswamy" wrote:
Ben,
On 23/01/18, 2:01 AM, "Ben Pfaff" wrote:
I guess I'm probably th
>
> On Thu, Feb 15, 2018 at 05:57:58PM +, Manohar Krishnappa
Chidambaraswamy wrote:
> > [Adding to my previous reply]
> >
> > Ben,
> >
> > “[manu] Do you mean using meters in dp-netdev instead of token-bucket.
I don’t know much a
t;
> What do you think?
>
> Jan
>
> > -Original Message-
> > From: Ben Pfaff [mailto:b...@ovn.org]
> > Sent: Friday, 16 February, 2018 23:54
> > To: Jan Scheurich
> > Cc: Manohar Krishnappa Chidambaraswamy
; d...@openvsw
eter (like "ofctl
add-global-meter meter="slowpath"...) which is not tied to any bridge or a new
CLI like what was proposed in this patch before.
Please let me know your thoughts.
Thanx
Manu
On 20/02/18, 11:20 AM, "Manohar Krishnappa Chidambaraswamy"
wrote:
Thanx B
patch?
Thanx
Manu
On 07/03/18, 6:54 PM, "ovs-dev-boun...@openvswitch.org on behalf of Manohar
Krishnappa Chidambaraswamy" wrote:
Ben,
While digging further on how OFPM_SLOWPATH can be used for rate-limiting
upcalls. Here is what I found.
1. Support for OFPM13_SLOW
Problem:
In user-space tunneling implementation, tnl_arp_snoop() snoops only ARP
*reply* packets to resolve tunnel nexthop IP addresses to MAC addresses.
Normally the ARP requests are periodically sent by the local host IP stack,
so that the ARP cache in OVS is refreshed and entries do not
Thanx Ben.
-Manu
On 11/04/18, 4:57 AM, "Ben Pfaff" wrote:
On Thu, Apr 05, 2018 at 12:20:27PM +0000, Manohar Krishnappa
Chidambaraswamy wrote:
> Problem:
>
> In user-space tunneling implementation, tnl_arp_snoop() snoops only ARP
> *rep
Hi
Rebased to master and adapted to the new dpif-netdev-perf counters.
As explained in v2 thread, OFPM_SLOWPATH meters cannot be used as is
for rate-limiting upcalls, hence reverted back to the simpler method
using token bucket.
Could you please review this patch?
Thanx
Manu
v2: https://patchwo
Problem:
Received LACP/CFM/BFD/STP/LLDP slow protocols' packets are not captured in
ovs-tcpdump.
Fix:
Add mirror support for slow protocols.
Signed-off-by: Manohar K C
CC: Jan Scheurich
---
ofproto/ofproto-dpif-xlate.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/ofp
Hi Ben,
Thanx for the review. Please see inline.
On 08/05/18, 9:12 PM, "Ben Pfaff" wrote:
On Tue, May 08, 2018 at 08:13:10AM +0000, Manohar Krishnappa
Chidambaraswamy wrote:
> Problem:
>
> Received LACP/CFM/BFD/STP/LLDP slow protocols' pac
Ben,
Here is the v2 patch based on your suggestion. Please let me know if you have
any other comments.
Thanx
Manu
Problem:
Received LACP/CFM/BFD/STP/LLDP slow protocols' packets are not captured in
ovs-tcpdump.
Fix:
Add mirror support for slow protocols.
Signed-off-by: Manohar K
Problem:
During port DOWN->UP of link (slave) in a LACP bond, after receiving the
LACPDU with SYNC set for both actor and partner, the bond-slave remains
"disabled" until OVS main thread runs LACP state machine and eventually
"enables" the bond-slave. With this, we have observed delays in
or in
function dpif_netdev_get_stats() as stats->n_missed, otherwise the overall
number of reported packets may not match the total number of packets processed.
[manu] Thanx. Will fix it.
Other comments in-line.
Regards, Jan
> From: Manohar Krishnappa Chidambaraswa
Jan,
Have addressed your comments/suggestions. Please take a look and let me
know if you have any more comments.
Signed-off-by: Manohar K C
CC: Jan Scheurich
---
v3 : v2 rebased to master and adpated to dpif-netdev-perf counters.
https://patchwork.ozlabs.org/patch/909676/
v2 : v1 rebased
1/2: Fix packet drops on LACP bond after link up
Problem:
During port DOWN->UP of link (slave) in a LACP bond, after receiving the
LACPDU with SYNC set for both actor and partner, the bond-slave remains
"disabled" until OVS main thread runs LACP state machine and eventually
"enables" the
2/2: Fix packet drops on LACP bond after link up
Problem:
On certain Fortville NICs it has been observed that PHY UP detection can
get delayed (sometimes up to 4-5 secs). When the driver fails to fetch
PHY status as UP even though its actually UP, LACP packets can get
exchanged and LACP
31 matches
Mail list logo