date:20180620

[ovs-dev] 答复: [PATCH] dpif-netdev:Delete port check in do_add_port

2018-06-20 Thread Linhaifeng

For the performance problem. When add 3000 or more ports it costs too more time 
and it is not needed.

port_add function in ofproto-dpif.c have checked it used dpif_port_exists so we 
really not need to check it again in do_add_port

-邮件原件-
发件人: Ben Pfaff [mailto:b...@ovn.org] 
发送时间: 2018年5月10日 5:10
收件人: Linhaifeng 
抄送: d...@openvswitch.org
主题: Re: [ovs-dev] [PATCH] dpif-netdev:Delete port check in do_add_port

On Thu, Apr 26, 2018 at 03:12:51PM +0800, Haifeng Lin wrote:
> It is not need check port exist in do_add_port because it had check in 
> port_add.
> 
> Change-Id: Ie66206b40e305cef5f5b20af765c3128ccec6782
> Signed-off-by: Haifeng Lin 

Can you explain the problem and the solution in a little more detail?

Thanks,

Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] dpif-netdev: Avoid reordering of packets in a batch with same megaflow

2018-06-20 Thread Vishal Deep Ajmera


Thanks for the patch! I didn't review the patch, but just have a question: does 
this issue exist only for dpif-netdev, or does kernel datapath has same issue?

I am not familiar with kernel data-path and don’t know if it also uses 
flow-based batching as in dpif-netdev.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] [RFC] ovn-controller: Experiment with restricting access to columns.

2018-06-20 Thread Ben Pfaff

On Thu, Jun 14, 2018 at 11:57:19AM -0700, Han Zhou wrote:
> On Thu, Jun 14, 2018 at 10:40 AM, Ben Pfaff  wrote:
> >
> > On Thu, Jun 14, 2018 at 10:17:58AM -0700, Han Zhou wrote:
> > > On Thu, Jun 14, 2018 at 10:09 AM, Ben Pfaff  wrote:
> > > >
> > > > On Wed, Jun 13, 2018 at 08:29:28PM -0700, Han Zhou wrote:
> > > > > On Wed, Jun 13, 2018 at 3:37 PM, Ben Pfaff  wrote:
> > > > > >
> > > > > > To make ovn-controller recompute incrementally, we need accurate
> > > > > > dependencies for each function that reads or writes a table.  It's
> > > > > > currently difficult to be sure about these dependencies, and
> certainly
> > > > > > difficult to maintain them over time, because there's no way to
> > > actually
> > > > > > enforce them.
> > > > > >
> > > > > > This commit experiments with an approach that allows for fairly
> > > > > > fine-grained access control within ovn-controller to tables and
> > > columns.
> > > > > > It's based on generating a new version of the IDL data structures
> for
> > > each
> > > > > > case where we want different access control.  All of these data
> > > structures
> > > > > > have the same format, but the columns that a given piece of code
> is
> > > not
> > > > > > supposed to touch are renamed to discourage programmers from using
> > > them,
> > > > > > e.g. they're given names suffixed with "__accessdenied".  (This
> means
> > > > > > that there is no runtime overhead to the access control since it
> only
> > > > > > requires a cast to convert between the regular and restricted
> > > versions.)
> > > > > > In addition, when a columns is supposed to be read-only,
> functions for
> > > > > > modifying the column are not supplied.
> > > > > >
> > > > > > This commit only tries out this experiment for a single file
> within
> > > > > > ovn-controller, the BFD implementation (mostly because that's
> > > > > > alphabetically first, no other real reason).  It would require a
> > > little
> > > > > > more work to apply it everywhere, but it's probably not a huge
> deal.
> > > > > >
> > > > > > Comments?
> > > > > >
> > > > > > CC: Han Zhou 
> > > > > > Signed-off-by: Ben Pfaff 
> > > > > > ---
> > > > > >  ovn/controller/automake.mk |   5 +
> > > > > >  ovn/controller/bfd-vswitch-idl.def |  21 
> > > > > >  ovn/controller/bfd.c   |  20 ++--
> > > > > >  ovn/controller/bfd.h   |   8 +-
> > > > > >  ovn/controller/ovn-controller.c|  13 ++-
> > > > > >  ovsdb/ovsdb-idlc.in| 223
> > > ++
> > > > > ++-
> > > > > >  6 files changed, 268 insertions(+), 22 deletions(-)
> > > > > >  create mode 100644 ovn/controller/bfd-vswitch-idl.def
> > > > > >
> > > > >
> > > > > I wanted to have a quick test but it didn't pass the compile:
> > > > > In file included from ovn/controller/bfd.c:17:0:
> > > > > ovn/controller/bfd.h:19:44: fatal error:
> > > ovn/controller/bfd-vswitch-idl.h:
> > > > > No such file or directory
> > > >
> > > > Hmm.  That's a little puzzling.  This file should get automatically
> > > > generated by "make".  I assume that I messed up a dependency
> somewhere,
> > > > but at first glance I can't see the problem.
> > > >
> > > > > I didn't debug, but by looking at the code I got the idea. It
> ensures
> > > the
> > > > > purpose is declared through the generated data type and violations
> are
> > > > > captured at compile time.
> > > > > I think this is a brilliant way to achieve the check with such a
> small
> > > > > change, however, I am not sure how is it supposed to help for
> generating
> > > > > the dependency. I think instead of caring about whether it is
> > > read-only, we
> > > > > should care about whether it is write-only.
> > > > >
> > > > > For example, a engine node A reads on Table T1's column C1, reads &
> > > writes
> > > > > on Table T2's column C2, and writes on T3's C3. In this case A
> depends
> > > on
> > > > > T1 and T2, but not depends on T3.
> > > > > So I think what matters to the dependency generation is whether it
> is
> > > > > Write-Only. Read-Only is no different from ReadWrite.
> > > > >
> > > > > If my understanding is correct (that we don't care about the
> difference
> > > > > between RO and RW), for WO columns, we can simply just don't
> monitor its
> > > > > change. Then we don't even need this feature from dependency
> generation
> > > > > point of view.
> > > > > Did I miss something?
> > > >
> > > > It's easy enough to add support for write-only columns here.  I'll add
> > > > that in the next version.
> > > >
> > > > > Another thing, however, I think is really important for the
> dependency
> > > > > generation is the columns that reference other tables, e.g.
> bfd_run()
> > > > > doesn't has table "ovsrec_port" as input, but in fact it depends on
> this
> > > > > table by referencing from ovsrec_bridge->ports. We need the table
> being
> > > > > referenced appear in the input parameters.
> > > > > The approach in the patch may not solve that problem di

[ovs-dev] 答复: [bug] ovs crash when call xlate_normal_flood

2018-06-20 Thread Linhaifeng

Or stop upcall thread before xlate_remove_ofproto in destruct.

发件人: Linhaifeng
发送时间: 2018年6月21日 13:49
收件人: 'd...@openvswitch.org' 
主题: [bug] ovs crash when call xlate_normal_flood

Should we use rwlock to use xbridge->xbundles? xbridge->xbundles may write in 
main thread and read in upcall thread.

The crash stack as follow:
#5  0x004a04e8 in xlate_normal_flood (ctx=ctx@entry=0x7faeee7b6f30, 
in_xbundle=in_xbundle@entry=0x553d950, vlan=vlan@entry=0) at 
ofproto/ofproto_dpif_xlate.c:2509
2509   in ofproto/ofproto_dpif_xlate.c
(gdb) info locals
xbundle = 0xffe8
(gdb) p xbundle->ofbundle
Cannot access memory at address 0xfff8
(gdb) p in_xbundle->ofbundle
$5 = (struct ofbundle *) 0x0
(gdb) p in_xbundle
$6 = (struct xbundle *) 0x553d950
(gdb) p *in_xbundle
$7 = {hmap_node = {hash = 0, next = 0x0}, ofbundle = 0x0, list_node = {prev = 
0x0, next = 0x0}, xbridge = 0x0, xports = {prev = 0x0, next = 0x0}, name = 0x0, 
bond = 0x0, lacp = 0x0, vlan_mode = PORT_VLAN_ACCESS, vlan = 0,
  trunks = 0x0, use_priority_tags = false, floodable = false, protected = 
false, external_id = 0}

(gdb) bt
#0  0x7fb05ea85197 in raise () from /usr/lib64/libc.so.6
#1  0x7fb05ea86888 in abort () from /usr/lib64/libc.so.6
#2  0x0065e1e9 in PAT_abort ()
#3  0x0065b32d in patchIllInsHandler ()
#4  
#5  0x004a04e8 in xlate_normal_flood (ctx=ctx@entry=0x7faeee7b6f30, 
in_xbundle=in_xbundle@entry=0x553d950, vlan=vlan@entry=0) at 
ofproto/ofproto_dpif_xlate.c:2509
#6  0x004a0e6e in xlate_normal (ctx=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:2736
#7  xlate_output_action (ctx=ctx@entry=0x7faeee7b6f30, port=, 
max_len=, may_packet_in=may_packet_in@entry=true) at 
ofproto/ofproto_dpif_xlate.c:4312
#8  0x0049d240 in do_xlate_actions (ofpacts=, 
ofpacts_len=, ctx=ctx@entry=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:5262
#9  0x0049e410 in xlate_recursively (deepens=true, rule=0x6a4be00, 
ctx=0x7faeee7b6f30) at ofproto/ofproto_dpif_xlate.c:3587
#10 xlate_table_action (ctx=0x7faeee7b6f30, in_port=, 
table_id=, may_packet_in=, 
honor_table_miss=) at ofproto/ofproto_dpif_xlate.c:3654
#11 0x0049faf7 in compose_output_action__ 
(ctx=ctx@entry=0x7faeee7b6f30, ofp_port=, xr=, 
check_stp=check_stp@entry=true) at ofproto/ofproto_dpif_xlate.c:3317
#12 0x004a0126 in compose_output_action (xr=, 
ofp_port=, ctx=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:3567
#13 output_normal (ctx=ctx@entry=0x7faeee7b6f30, 
out_xbundle=out_xbundle@entry=0x3005770, vlan=vlan@entry=0) at 
ofproto/ofproto_dpif_xlate.c:2113
#14 0x004a0511 in xlate_normal_flood (ctx=ctx@entry=0x7faeee7b6f30, 
in_xbundle=in_xbundle@entry=0x3008a40, vlan=vlan@entry=0) at 
ofproto/ofproto_dpif_xlate.c:2517
#15 0x004a0e6e in xlate_normal (ctx=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:2736
#16 xlate_output_action (ctx=ctx@entry=0x7faeee7b6f30, port=, 
max_len=, may_packet_in=may_packet_in@entry=true) at 
ofproto/ofproto_dpif_xlate.c:4312
#17 0x0049d240 in do_xlate_actions (ofpacts=, 
ofpacts_len=, ctx=ctx@entry=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:5262
#18 0x0049e410 in xlate_recursively (deepens=true, rule=0x6a32500, 
ctx=0x7faeee7b6f30) at ofproto/ofproto_dpif_xlate.c:3587
#19 xlate_table_action (ctx=0x7faeee7b6f30, in_port=, 
table_id=, may_packet_in=, 
honor_table_miss=) at ofproto/ofproto_dpif_xlate.c:3654
#20 0x0049faf7 in compose_output_action__ 
(ctx=ctx@entry=0x7faeee7b6f30, ofp_port=, xr=, 
check_stp=check_stp@entry=true) at ofproto/ofproto_dpif_xlate.c:3317
#21 0x004a0126 in compose_output_action (xr=, 
ofp_port=, ctx=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:3567
#22 output_normal (ctx=ctx@entry=0x7faeee7b6f30, 
out_xbundle=out_xbundle@entry=0x93e3e10, vlan=vlan@entry=0) at 
ofproto/ofproto_dpif_xlate.c:2113
#23 0x004a0511 in xlate_normal_flood (ctx=ctx@entry=0x7faeee7b6f30, 
in_xbundle=in_xbundle@entry=0x894de90, vlan=vlan@entry=0) at 
ofproto/ofproto_dpif_xlate.c:2517
#24 0x004a0e6e in xlate_normal (ctx=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:2736
#25 xlate_output_action (ctx=ctx@entry=0x7faeee7b6f30, port=, 
max_len=, may_packet_in=may_packet_in@entry=true) at 
ofproto/ofproto_dpif_xlate.c:4312
#26 0x0049d240 in do_xlate_actions (ofpacts=, 
ofpacts_len=, ctx=ctx@entry=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:5262
#27 0x004a27df in xlate_actions (xin=xin@entry=0x7faeee7b8550, 
xout=xout@entry=0x7faeee7dd320) at ofproto/ofproto_dpif_xlate.c:6119
#28 0x004959bb in upcall_xlate (wc=0x7faeee7dd378, 
odp_actions=0x7faeee7dd338, upcall=0x7faeee7dd2c0, udpif=0x1807190) at 
ofproto/ofproto_dpif_upcall.c:1185
#29 process_upcall (udpif=udpif@entry=0x1807190, 
upcall=upcall@entry=0x7faeee7dd2c0, 
odp_actions=odp_actions@entry=0x7faeee7dd338, wc=wc@entry=0x7faeee7dd378) at 
ofproto/ofproto_dpif_upcall.c:1322
#30 0x0049716c in recv_upcalls (hand

[ovs-dev] [bug] ovs crash when call xlate_normal_flood

2018-06-20 Thread Linhaifeng

Should we use rwlock to use xbridge->xbundles? xbridge->xbundles may write in 
main thread and read in upcall thread.

The crash stack as follow:
#5  0x004a04e8 in xlate_normal_flood (ctx=ctx@entry=0x7faeee7b6f30, 
in_xbundle=in_xbundle@entry=0x553d950, vlan=vlan@entry=0) at 
ofproto/ofproto_dpif_xlate.c:2509
2509   in ofproto/ofproto_dpif_xlate.c
(gdb) info locals
xbundle = 0xffe8
(gdb) p xbundle->ofbundle
Cannot access memory at address 0xfff8
(gdb) p in_xbundle->ofbundle
$5 = (struct ofbundle *) 0x0
(gdb) p in_xbundle
$6 = (struct xbundle *) 0x553d950
(gdb) p *in_xbundle
$7 = {hmap_node = {hash = 0, next = 0x0}, ofbundle = 0x0, list_node = {prev = 
0x0, next = 0x0}, xbridge = 0x0, xports = {prev = 0x0, next = 0x0}, name = 0x0, 
bond = 0x0, lacp = 0x0, vlan_mode = PORT_VLAN_ACCESS, vlan = 0,
  trunks = 0x0, use_priority_tags = false, floodable = false, protected = 
false, external_id = 0}

(gdb) bt
#0  0x7fb05ea85197 in raise () from /usr/lib64/libc.so.6
#1  0x7fb05ea86888 in abort () from /usr/lib64/libc.so.6
#2  0x0065e1e9 in PAT_abort ()
#3  0x0065b32d in patchIllInsHandler ()
#4  
#5  0x004a04e8 in xlate_normal_flood (ctx=ctx@entry=0x7faeee7b6f30, 
in_xbundle=in_xbundle@entry=0x553d950, vlan=vlan@entry=0) at 
ofproto/ofproto_dpif_xlate.c:2509
#6  0x004a0e6e in xlate_normal (ctx=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:2736
#7  xlate_output_action (ctx=ctx@entry=0x7faeee7b6f30, port=, 
max_len=, may_packet_in=may_packet_in@entry=true) at 
ofproto/ofproto_dpif_xlate.c:4312
#8  0x0049d240 in do_xlate_actions (ofpacts=, 
ofpacts_len=, ctx=ctx@entry=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:5262
#9  0x0049e410 in xlate_recursively (deepens=true, rule=0x6a4be00, 
ctx=0x7faeee7b6f30) at ofproto/ofproto_dpif_xlate.c:3587
#10 xlate_table_action (ctx=0x7faeee7b6f30, in_port=, 
table_id=, may_packet_in=, 
honor_table_miss=) at ofproto/ofproto_dpif_xlate.c:3654
#11 0x0049faf7 in compose_output_action__ 
(ctx=ctx@entry=0x7faeee7b6f30, ofp_port=, xr=, 
check_stp=check_stp@entry=true) at ofproto/ofproto_dpif_xlate.c:3317
#12 0x004a0126 in compose_output_action (xr=, 
ofp_port=, ctx=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:3567
#13 output_normal (ctx=ctx@entry=0x7faeee7b6f30, 
out_xbundle=out_xbundle@entry=0x3005770, vlan=vlan@entry=0) at 
ofproto/ofproto_dpif_xlate.c:2113
#14 0x004a0511 in xlate_normal_flood (ctx=ctx@entry=0x7faeee7b6f30, 
in_xbundle=in_xbundle@entry=0x3008a40, vlan=vlan@entry=0) at 
ofproto/ofproto_dpif_xlate.c:2517
#15 0x004a0e6e in xlate_normal (ctx=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:2736
#16 xlate_output_action (ctx=ctx@entry=0x7faeee7b6f30, port=, 
max_len=, may_packet_in=may_packet_in@entry=true) at 
ofproto/ofproto_dpif_xlate.c:4312
#17 0x0049d240 in do_xlate_actions (ofpacts=, 
ofpacts_len=, ctx=ctx@entry=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:5262
#18 0x0049e410 in xlate_recursively (deepens=true, rule=0x6a32500, 
ctx=0x7faeee7b6f30) at ofproto/ofproto_dpif_xlate.c:3587
#19 xlate_table_action (ctx=0x7faeee7b6f30, in_port=, 
table_id=, may_packet_in=, 
honor_table_miss=) at ofproto/ofproto_dpif_xlate.c:3654
#20 0x0049faf7 in compose_output_action__ 
(ctx=ctx@entry=0x7faeee7b6f30, ofp_port=, xr=, 
check_stp=check_stp@entry=true) at ofproto/ofproto_dpif_xlate.c:3317
#21 0x004a0126 in compose_output_action (xr=, 
ofp_port=, ctx=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:3567
#22 output_normal (ctx=ctx@entry=0x7faeee7b6f30, 
out_xbundle=out_xbundle@entry=0x93e3e10, vlan=vlan@entry=0) at 
ofproto/ofproto_dpif_xlate.c:2113
#23 0x004a0511 in xlate_normal_flood (ctx=ctx@entry=0x7faeee7b6f30, 
in_xbundle=in_xbundle@entry=0x894de90, vlan=vlan@entry=0) at 
ofproto/ofproto_dpif_xlate.c:2517
#24 0x004a0e6e in xlate_normal (ctx=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:2736
#25 xlate_output_action (ctx=ctx@entry=0x7faeee7b6f30, port=, 
max_len=, may_packet_in=may_packet_in@entry=true) at 
ofproto/ofproto_dpif_xlate.c:4312
#26 0x0049d240 in do_xlate_actions (ofpacts=, 
ofpacts_len=, ctx=ctx@entry=0x7faeee7b6f30) at 
ofproto/ofproto_dpif_xlate.c:5262
#27 0x004a27df in xlate_actions (xin=xin@entry=0x7faeee7b8550, 
xout=xout@entry=0x7faeee7dd320) at ofproto/ofproto_dpif_xlate.c:6119
#28 0x004959bb in upcall_xlate (wc=0x7faeee7dd378, 
odp_actions=0x7faeee7dd338, upcall=0x7faeee7dd2c0, udpif=0x1807190) at 
ofproto/ofproto_dpif_upcall.c:1185
#29 process_upcall (udpif=udpif@entry=0x1807190, 
upcall=upcall@entry=0x7faeee7dd2c0, 
odp_actions=odp_actions@entry=0x7faeee7dd338, wc=wc@entry=0x7faeee7dd378) at 
ofproto/ofproto_dpif_upcall.c:1322
#30 0x0049716c in recv_upcalls (handler=0x64775d0, handler=0x64775d0) 
at ofproto/ofproto_dpif_upcall.c:863
#31 0x0049764a in udpif_upcall_handler (arg=0x64775d0) at 
ofproto/ofproto_dpif_upcall.c:783
#32 0x000

Re: [ovs-dev] [PATCH] dpif-netdev: Avoid reordering of packets in a batch with same megaflow

2018-06-20 Thread Han Zhou

On Sat, Jun 16, 2018 at 7:21 PM, Vishal Deep Ajmera <
vishal.deep.ajm...@ericsson.com> wrote:
>
> OVS reads packets in batches from a given port and packets in the
> batch are subjected to potentially 3 levels of lookups to identify
> the datapath megaflow entry (or flow) associated with the packet.
> Each megaflow entry has a dedicated buffer in which packets that match
> the flow classification criteria are collected. This buffer helps OVS
> perform batch processing for all packets associated with a given flow.
>
> Each packet in the received batch is first subjected to lookup in the
> Exact Match Cache (EMC). Each EMC entry will point to a flow. If the
> EMC lookup is successful, the packet is moved from the rx batch to the
> per-flow buffer.
>
> Packets that did not match any EMC entry are rearranged in the rx batch
> at the beginning and are now subjected to a lookup in the megaflow cache.
> Packets that match a megaflow cache entry are *appended* to the per-flow
> buffer.
>
> Packets that do not match any megaflow entry are subjected to slow-path
> processing through the upcall mechanism. This cannot change the order of
> packets as by definition upcall processing is only done for packets
> without matching megaflow entry.
>
> The EMC entry match fields encompass all potentially significant header
> fields, typically more than specified in the associated flow's match
> criteria. Hence, multiple EMC entries can point to the same flow. Given
> that per-flow batching happens at each lookup stage, packets belonging
> to the same megaflow can get re-ordered because some packets match EMC
> entries while others do not.
>
> The following example can illustrate the issue better. Consider
> following batch of packets (labelled P1 to P8) associated with a single
> TCP connection and associated with a single flow. Let us assume that
> packets with just the ACK bit set in TCP flags have been received in a
> prior batch also and a corresponding EMC entry exists.
>
> 1. P1 (TCP Flag: ACK)
> 2. P2 (TCP Flag: ACK)
> 3. P3 (TCP Flag: ACK)
> 4. P4 (TCP Flag: ACK, PSH)
> 5. P5 (TCP Flag: ACK)
> 6. P6 (TCP Flag: ACK)
> 7. P7 (TCP Flag: ACK)
> 8. P8 (TCP Flag: ACK)
>
> The megaflow classification criteria does not include TCP flags while
> the EMC match criteria does. Thus, all packets other than P4 match
> the existing EMC entry and are moved to the per-flow packet batch.
> Subsequently, packet P4 is moved to the same per-flow packet batch as
> a result of the megaflow lookup. Though the packets have all been
> correctly classified as being associated with the same flow, the
> packet order has not been preserved because of the per-flow batching
> performed during the EMC lookup stage. This packet re-ordering has
> performance implications for TCP applications.
>
> This patch preserves the packet ordering by performing the per-flow
> batching after both the EMC and megaflow lookups are complete. As an
> optimization, packets are flow-batched in emc processing till any
> packet in the batch has an EMC miss.
>
> A new flow map is maintained to keep the original order of packet
> along with flow information. Post fastpath processing, packets from
> flow map are *appended* to per-flow buffer.
>
> Signed-off-by: Vishal Deep Ajmera 
> Co-authored-by: Venkatesan Pradeep 
> Signed-off-by: Venkatesan Pradeep 
> ---
>  lib/dpif-netdev.c | 79
++-
>  1 file changed, 66 insertions(+), 13 deletions(-)


Thanks for the patch! I didn't review the patch, but just have a question:
does this issue exist only for dpif-netdev, or does kernel datapath has
same issue?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 2/2] ovndb-servers: Set connection table when using

2018-06-20 Thread Han Zhou

It's better to replace "ovndb-servers" to "ovndb-servers.ocf" in the title.
Probably Ben will take care of that when applying the patch.

Acked-by: Han Zhou 

On Fri, Jun 8, 2018 at 6:33 PM, aginwala  wrote:

> load balancer to manage ovndb clusters via pacemaker.
>
> This is will allow setting inactivity probe on the master node.
> For pacemaker to manage ovndb resources via LB, we skipped creating
> connection
> table and hence the inactivity probe was getting set to 5000 by default.
> In order to over-ride it we need this table. However, we need to skip
> slaves
> listening on local sb and nb connections table so that LB feature is
> intact and only master is listening on 0.0.0.0
>
> e.g --remote=db:OVN_Southbound,SB_Global,connections and
> --remote=db:OVN_Northbound,NB_Global,connections
>
> will be skipped for slave SB and NB dbs respectively by unsetting
> --db-sb-use-remote-in-db  and --db-nb-use-remote-in-db in ovn-ctl.
>
> Signed-off-by: aginwala 
> ---
>  ovn/utilities/ovndb-servers.ocf | 39 +++---
> -
>  1 file changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/ovn/utilities/ovndb-servers.ocf
> b/ovn/utilities/ovndb-servers.ocf
> index 9391b89..52141c7 100755
> --- a/ovn/utilities/ovndb-servers.ocf
> +++ b/ovn/utilities/ovndb-servers.ocf
> @@ -172,25 +172,29 @@ ovsdb_server_notify() {
>  ${OVN_CTL} --ovn-manage-ovsdb=no start_northd
>  fi
>
> -# Not needed while listening on 0.0.0.0 as we do not want to allow
> -# local binds. However, it is needed if vip ip is binded to nodes.
> -if [ "x${LISTEN_ON_MASTER_IP_ONLY}" = xyes ]; then
> -conn=`ovn-nbctl get NB_global . connections`
> -if [ "$conn" == "[]" ]
> -then
> -ovn-nbctl -- --id=@conn_uuid create Connection \
> -target="p${NB_MASTER_PROTO}\:${NB_MASTER_PORT}\:${MASTER_IP}" \
> +# In order to over-ride inactivity_probe for LB use case, we need
> to
> +# create connection entry to listen on 0.0.0.0 for master node.
> +if [ "x${LISTEN_ON_MASTER_IP_ONLY}" = xno ]; then
> +   LISTON_ON_IP="0.0.0.0"
> +else
> +   LISTON_ON_IP=${MASTER_IP}
> +fi
> +conn=`ovn-nbctl get NB_global . connections`
> +if [ "$conn" == "[]" ]
> +then
> +ovn-nbctl -- --id=@conn_uuid create Connection \
> +target="p${NB_MASTER_PROTO}\:${NB_MASTER_PORT}\:${LISTON_ON_IP}" \
>  inactivity_probe=$INACTIVE_PROBE -- set NB_Global .
> connections=@conn_uuid
> -fi
> +fi
>
> -conn=`ovn-sbctl get SB_global . connections`
> -if [ "$conn" == "[]" ]
> -then
> -ovn-sbctl -- --id=@conn_uuid create Connection \
> -target="p${SB_MASTER_PROTO}\:${SB_MASTER_PORT}\:${MASTER_IP}" \
> +conn=`ovn-sbctl get SB_global . connections`
> +if [ "$conn" == "[]" ]
> +then
> +ovn-sbctl -- --id=@conn_uuid create Connection \
> +target="p${SB_MASTER_PROTO}\:${SB_MASTER_PORT}\:${LISTON_ON_IP}" \
>  inactivity_probe=$INACTIVE_PROBE -- set SB_Global .
> connections=@conn_uuid
> -fi
>  fi
> +
>  else
>  if [ "$MANAGE_NORTHD" = "yes" ]; then
>  # Stop ovn-northd service. Set --ovn-manage-ovsdb=no so that
> @@ -355,7 +359,10 @@ ovsdb_server_start() {
>  set $@ --db-nb-sync-from-proto=${NB_MASTER_PROTO}
>  set $@ --db-sb-sync-from-port=${SB_MASTER_PORT}
>  set $@ --db-sb-sync-from-proto=${SB_MASTER_PROTO}
> -
> +if [ "x${LISTEN_ON_MASTER_IP_ONLY}" = xno ]; then
> +set $@ --db-sb-use-remote-in-db="no"
> +set $@ --db-nb-use-remote-in-db="no"
> +fi
>  fi
>
>  $@ start_ovsdb
> --
> 1.9.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovs-ofctl: Update man page on conntrack supported platforms.

2018-06-20 Thread Justin Pettit



> On Jun 20, 2018, at 1:59 PM, Ben Pfaff  wrote:
> 
> On Wed, Jun 20, 2018 at 01:37:07PM -0700, Justin Pettit wrote:
>> Signed-off-by: Justin Pettit 
> 
> Acked-by: Ben Pfaff 

Thanks.  I pushed this to master.

--Justin


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovs-ofctl: Update man page on conntrack supported platforms.

2018-06-20 Thread Ben Pfaff

On Wed, Jun 20, 2018 at 01:37:07PM -0700, Justin Pettit wrote:
> Signed-off-by: Justin Pettit 

Acked-by: Ben Pfaff 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] ovs-ofctl: Update man page on conntrack supported platforms.

2018-06-20 Thread Justin Pettit

Signed-off-by: Justin Pettit 
---
 utilities/ovs-ofctl.8.in | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/utilities/ovs-ofctl.8.in b/utilities/ovs-ofctl.8.in
index 4f8555aa3379..c5735cafc23f 100644
--- a/utilities/ovs-ofctl.8.in
+++ b/utilities/ovs-ofctl.8.in
@@ -1239,9 +1239,7 @@ continue pipeline processing). As such, it is strongly 
recommended that
 multiple flows should not execute \fBct\fR to reassemble fragments from the
 same IP message.
 .IP
-Currently, connection tracking is only available on Linux kernels with the
-nf_conntrack module loaded. The \fBct\fR action was introduced in Open vSwitch
-2.5.
+The \fBct\fR action was introduced in Open vSwitch 2.5.
 .
 .IP \fBct_clear\fR
 Clears connection tracking state from the flow, zeroing
-- 
2.7.4

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC PATCH v2 1/1] dpdk: Support both shared and per port mempools.

2018-06-20 Thread Ian Stokes


On 6/20/2018 6:24 PM, Kevin Traynor wrote:

On 06/20/2018 01:34 PM, Ian Stokes wrote:

On 6/19/2018 12:11 PM, Kevin Traynor wrote:

On 06/11/2018 05:37 PM, Ian Stokes wrote:

This commit re-introduces the concept of shared mempools as the default
memory model for DPDK devices. Per port mempools are still available but
must be enabled explicitly by a user.



Hi Ian, thanks for v2, comments below


Thanks for the review Kevin, comments inline.




OVS previously used a shared mempool model for ports with the same MTU
and socket configuration. This was replaced by a per port mempool model
to address issues flagged by users such as:

https://mail.openvswitch.org/pipermail/ovs-discuss/2016-September/042560.html


However the per port model potentially requires an increase in memory
resource requirements to support the same number of ports and
configuration
as the shared port model.

This is considered a blocking factor for current deployments of OVS
when upgrading to future OVS releases as a user may have to redimension
memory for the same deployment configuration. This may not be
possible for
users.

This commit resolves the issue by re-introducing shared mempools as
the default memory behaviour in OVS DPDK but also refactors the memory
configuration code to allow for per port mempools.

This patch adds a new global config option, per-port-mp, that


s/per-port-mp/per-port-memory/


Apologies, I spotted a few of these 'per-port-mp' myself, I believe it's
in the documentation as well. I have them fixed for the next revision.




controls the enablement of per port mempools for DPDK devices.

  ovs-vsctl set Open_vSwitch . other_config:per-port-memory=true

This value defaults to false; to enable per port memory support,
this field should be set to true when setting other global parameters
on init (such as "dpdk-socket-mem", for example). Changing the value at
runtime is not supported, and requires restarting the vswitch
daemon.

The mempool sweep functionality is also replaced with the
sweep functionality from OVS 2.9 found in commits

c77f692 (netdev-dpdk: Free mempool only when no in-use mbufs.)
a7fb0a4 (netdev-dpdk: Add mempool reuse/free debug.)

As this patch is RFC there are a number of TO-DOs including adding a
memory calculation section to the documentation for both models. This is
expected to be completed in the v1 after RFC.

Signed-off-by: Ian Stokes 

---
v1 -> v2
* Rebase to head of master.
* Change global config option 'per-port-mp-enabled' to
'per-port-memory'.
in commit message & documentation and code.
* Specify in documentation that restart of daemon is only required if
per
port-port-memory is set after dpdk-init=true.
* Return comment 'Contains all 'struct dpdk_mp's.' which was lost in
previous refactor.
* Improve comments regarding unique mempool names in the shared mempool
usecase.
* Check per_port_mp condition first when verifying if new mempool is
required in netdev_dpdk_mempool_configure() for the shared mempool
usecase.
* Correctly return ret variable instead of 0 for function
netdev_dpdk_mempool_configure().
* Move VLOG_ERR regarding failure to create mempool for a device
prior to
dpdk_mp_create() returns.
* Add VLOG_DBG message flagging that the number of mbufs could not be
allocated and that it will be retried with half that amount.
* Fix indentation of VLOG_ERR in netdev_dpdk_mempool_configure().
* Handle EEXIST case for per port memory in function dpdk_mp_get() to
avoid duplication of dpdk_mps, correctly set refcount and return
correct dpdk_mp for the device to use.
---
   Documentation/automake.mk|   1 +
   Documentation/topics/dpdk/index.rst  |   1 +
   Documentation/topics/dpdk/memory.rst |  67 
   NEWS |   1 +
   lib/dpdk-stub.c  |   6 +
   lib/dpdk.c   |  12 ++
   lib/dpdk.h   |   1 +
   lib/netdev-dpdk.c| 298
+++
   vswitchd/vswitch.xml |  17 ++
   9 files changed, 304 insertions(+), 100 deletions(-)
   create mode 100644 Documentation/topics/dpdk/memory.rst

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 2202df4..141b33d 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -36,6 +36,7 @@ DOC_SOURCE = \
   Documentation/topics/dpdk/index.rst \
   Documentation/topics/dpdk/bridge.rst \
   Documentation/topics/dpdk/jumbo-frames.rst \
+Documentation/topics/dpdk/memory.rst \
   Documentation/topics/dpdk/pdump.rst \
   Documentation/topics/dpdk/phy.rst \
   Documentation/topics/dpdk/pmd.rst \
diff --git a/Documentation/topics/dpdk/index.rst
b/Documentation/topics/dpdk/index.rst
index 181f61a..cf24a7b 100644
--- a/Documentation/topics/dpdk/index.rst
+++ b/Documentation/topics/dpdk/index.rst
@@ -40,3 +40,4 @@ The DPDK Datapath
  /topics/dpdk/qos
  /topics/dpdk/pdump

Re: [ovs-dev] [PATCH 2/2] ovndb-servers: Set connection table when using

2018-06-20 Thread Numan Siddique

On Sat, Jun 9, 2018 at 7:03 AM, aginwala  wrote:

> load balancer to manage ovndb clusters via pacemaker.
>
> This is will allow setting inactivity probe on the master node.
> For pacemaker to manage ovndb resources via LB, we skipped creating
> connection
> table and hence the inactivity probe was getting set to 5000 by default.
> In order to over-ride it we need this table. However, we need to skip
> slaves
> listening on local sb and nb connections table so that LB feature is
> intact and only master is listening on 0.0.0.0
>
> e.g --remote=db:OVN_Southbound,SB_Global,connections and
> --remote=db:OVN_Northbound,NB_Global,connections
>
> will be skipped for slave SB and NB dbs respectively by unsetting
> --db-sb-use-remote-in-db  and --db-nb-use-remote-in-db in ovn-ctl.
>
> Signed-off-by: aginwala 
>

Acked-by: Numan Siddique 



> ---
>  ovn/utilities/ovndb-servers.ocf | 39 +++---
> -
>  1 file changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/ovn/utilities/ovndb-servers.ocf
> b/ovn/utilities/ovndb-servers.ocf
> index 9391b89..52141c7 100755
> --- a/ovn/utilities/ovndb-servers.ocf
> +++ b/ovn/utilities/ovndb-servers.ocf
> @@ -172,25 +172,29 @@ ovsdb_server_notify() {
>  ${OVN_CTL} --ovn-manage-ovsdb=no start_northd
>  fi
>
> -# Not needed while listening on 0.0.0.0 as we do not want to allow
> -# local binds. However, it is needed if vip ip is binded to nodes.
> -if [ "x${LISTEN_ON_MASTER_IP_ONLY}" = xyes ]; then
> -conn=`ovn-nbctl get NB_global . connections`
> -if [ "$conn" == "[]" ]
> -then
> -ovn-nbctl -- --id=@conn_uuid create Connection \
> -target="p${NB_MASTER_PROTO}\:${NB_MASTER_PORT}\:${MASTER_IP}" \
> +# In order to over-ride inactivity_probe for LB use case, we need
> to
> +# create connection entry to listen on 0.0.0.0 for master node.
> +if [ "x${LISTEN_ON_MASTER_IP_ONLY}" = xno ]; then
> +   LISTON_ON_IP="0.0.0.0"
> +else
> +   LISTON_ON_IP=${MASTER_IP}
> +fi
> +conn=`ovn-nbctl get NB_global . connections`
> +if [ "$conn" == "[]" ]
> +then
> +ovn-nbctl -- --id=@conn_uuid create Connection \
> +target="p${NB_MASTER_PROTO}\:${NB_MASTER_PORT}\:${LISTON_ON_IP}" \
>  inactivity_probe=$INACTIVE_PROBE -- set NB_Global .
> connections=@conn_uuid
> -fi
> +fi
>
> -conn=`ovn-sbctl get SB_global . connections`
> -if [ "$conn" == "[]" ]
> -then
> -ovn-sbctl -- --id=@conn_uuid create Connection \
> -target="p${SB_MASTER_PROTO}\:${SB_MASTER_PORT}\:${MASTER_IP}" \
> +conn=`ovn-sbctl get SB_global . connections`
> +if [ "$conn" == "[]" ]
> +then
> +ovn-sbctl -- --id=@conn_uuid create Connection \
> +target="p${SB_MASTER_PROTO}\:${SB_MASTER_PORT}\:${LISTON_ON_IP}" \
>  inactivity_probe=$INACTIVE_PROBE -- set SB_Global .
> connections=@conn_uuid
> -fi
>  fi
> +
>  else
>  if [ "$MANAGE_NORTHD" = "yes" ]; then
>  # Stop ovn-northd service. Set --ovn-manage-ovsdb=no so that
> @@ -355,7 +359,10 @@ ovsdb_server_start() {
>  set $@ --db-nb-sync-from-proto=${NB_MASTER_PROTO}
>  set $@ --db-sb-sync-from-port=${SB_MASTER_PORT}
>  set $@ --db-sb-sync-from-proto=${SB_MASTER_PROTO}
> -
> +if [ "x${LISTEN_ON_MASTER_IP_ONLY}" = xno ]; then
> +set $@ --db-sb-use-remote-in-db="no"
> +set $@ --db-nb-use-remote-in-db="no"
> +fi
>  fi
>
>  $@ start_ovsdb
> --
> 1.9.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 1/2] checkpatch: add quiet option

2018-06-20 Thread Aaron Conole

This allows scripts which only want to process error messages to silence
the normal 'warm and fuzzy' status messages from checkpatch.

Signed-off-by: Aaron Conole 
---
 utilities/checkpatch.py | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/utilities/checkpatch.py b/utilities/checkpatch.py
index 0a38ac571..cd781b576 100755
--- a/utilities/checkpatch.py
+++ b/utilities/checkpatch.py
@@ -81,6 +81,7 @@ checking_file = False
 total_line = 0
 colors = False
 spellcheck_comments = False
+quiet = False
 
 
 def get_color_end():
@@ -719,6 +720,7 @@ Check options:
 -h|--help  This help message
 -b|--skip-block-whitespace Skips the if/while/for whitespace tests
 -l|--skip-leading-whitespace   Skips the leading whitespace test
+-q|--quiet Only print error and warning information
 -s|--skip-signoff-linesTolerate missing Signed-off-by line
 -S|--spellcheck-comments   Check C comments for possible spelling mistakes
 -t|--skip-trailing-whitespace  Skips the trailing whitespace test"""
@@ -726,11 +728,12 @@ Check options:
 
 
 def ovs_checkpatch_print_result(result):
-global __warnings, __errors, total_line
+global quiet, __warnings, __errors, total_line
+
 if result < 0:
 print("Lines checked: %d, Warnings: %d, Errors: %d\n" %
   (total_line, __warnings, __errors))
-else:
+elif not quiet:
 print("Lines checked: %d, no obvious problems found\n" % (total_line))
 
 
@@ -768,14 +771,15 @@ if __name__ == '__main__':
   sys.argv[1:])
 n_patches = int(numeric_options[-1][1:]) if numeric_options else 0
 
-optlist, args = getopt.getopt(args, 'bhlstfS',
+optlist, args = getopt.getopt(args, 'bhlstfSq',
   ["check-file",
"help",
"skip-block-whitespace",
"skip-leading-whitespace",
"skip-signoff-lines",
"skip-trailing-whitespace",
-   "spellcheck-comments"])
+   "spellcheck-comments",
+   "quiet"])
 except:
 print("Unknown option encountered. Please rerun with -h for help.")
 sys.exit(-1)
@@ -800,6 +804,8 @@ if __name__ == '__main__':
 print(" Please install python enchant.")
 else:
 spellcheck_comments = True
+elif o in ("-q", "--quiet"):
+quiet = True
 else:
 print("Unknown option '%s'" % o)
 sys.exit(-1)
@@ -820,7 +826,8 @@ if __name__ == '__main__':
 patch = f.read()
 f.close()
 
-print('== Checking %s ("%s") ==' % (revision[0:12], name))
+if not quiet:
+print('== Checking %s ("%s") ==' % (revision[0:12], name))
 result = ovs_checkpatch_parse(patch, revision)
 ovs_checkpatch_print_result(result)
 if result:
@@ -837,7 +844,8 @@ if __name__ == '__main__':
 
 status = 0
 for filename in args:
-print('== Checking "%s" ==' % filename)
+if not quiet:
+print('== Checking "%s" ==' % filename)
 result = ovs_checkpatch_file(filename)
 if result:
 status = -1
-- 
2.14.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 2/2] checkpatch: Only consider certain signoffs

2018-06-20 Thread Aaron Conole

Formatted patches can contain a heirarchy of sign-offs.  This is true when
merging patches from different projects (eg. backports to the datapath
directory from the linux net project).

This means that a submitted backport will contain multiple signed-off
tags, and not all should be considered.

This commit updates checkpatch to only consider those signoff lines which
start at the beginning of a line.  So the following:

  Signed-off-by: Foo Bar 

should not trigger.

Signed-off-by: Aaron Conole 
---
 utilities/checkpatch.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/utilities/checkpatch.py b/utilities/checkpatch.py
index cd781b576..5a6d5f5ff 100755
--- a/utilities/checkpatch.py
+++ b/utilities/checkpatch.py
@@ -623,9 +623,9 @@ def ovs_checkpatch_parse(text, filename):
 hunks = re.compile('^(---|\+\+\+) (\S+)')
 hunk_differences = re.compile(
 r'^@@ ([0-9-+]+),([0-9-+]+) ([0-9-+]+),([0-9-+]+) @@')
-is_signature = re.compile(r'((\s*Signed-off-by: )(.*))$',
+is_signature = re.compile(r'^(Signed-off-by: )(.*)$',
   re.I | re.M | re.S)
-is_co_author = re.compile(r'(\s*(Co-authored-by: )(.*))$',
+is_co_author = re.compile(r'^(Co-authored-by: )(.*)$',
   re.I | re.M | re.S)
 is_gerrit_change_id = re.compile(r'(\s*(change-id: )(.*))$',
  re.I | re.M | re.S)
@@ -664,10 +664,10 @@ def ovs_checkpatch_parse(text, filename):
 print_error("Co-authored-by/Signed-off-by corruption")
 elif is_signature.match(line):
 m = is_signature.match(line)
-signatures.append(m.group(3))
+signatures.append(m.group(2))
 elif is_co_author.match(line):
 m = is_co_author.match(line)
-co_authors.append(m.group(3))
+co_authors.append(m.group(2))
 elif is_gerrit_change_id.match(line):
 print_error(
 "Remove Gerrit Change-Id's before submitting upstream.")
-- 
2.14.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC PATCH v2 1/1] dpdk: Support both shared and per port mempools.

2018-06-20 Thread Kevin Traynor

On 06/20/2018 01:34 PM, Ian Stokes wrote:
> On 6/19/2018 12:11 PM, Kevin Traynor wrote:
>> On 06/11/2018 05:37 PM, Ian Stokes wrote:
>>> This commit re-introduces the concept of shared mempools as the default
>>> memory model for DPDK devices. Per port mempools are still available but
>>> must be enabled explicitly by a user.
>>>
>>
>> Hi Ian, thanks for v2, comments below
> 
> Thanks for the review Kevin, comments inline.
> 
>>
>>> OVS previously used a shared mempool model for ports with the same MTU
>>> and socket configuration. This was replaced by a per port mempool model
>>> to address issues flagged by users such as:
>>>
>>> https://mail.openvswitch.org/pipermail/ovs-discuss/2016-September/042560.html
>>>
>>>
>>> However the per port model potentially requires an increase in memory
>>> resource requirements to support the same number of ports and
>>> configuration
>>> as the shared port model.
>>>
>>> This is considered a blocking factor for current deployments of OVS
>>> when upgrading to future OVS releases as a user may have to redimension
>>> memory for the same deployment configuration. This may not be
>>> possible for
>>> users.
>>>
>>> This commit resolves the issue by re-introducing shared mempools as
>>> the default memory behaviour in OVS DPDK but also refactors the memory
>>> configuration code to allow for per port mempools.
>>>
>>> This patch adds a new global config option, per-port-mp, that
>>
>> s/per-port-mp/per-port-memory/
> 
> Apologies, I spotted a few of these 'per-port-mp' myself, I believe it's
> in the documentation as well. I have them fixed for the next revision.
> 
>>
>>> controls the enablement of per port mempools for DPDK devices.
>>>
>>>  ovs-vsctl set Open_vSwitch . other_config:per-port-memory=true
>>>
>>> This value defaults to false; to enable per port memory support,
>>> this field should be set to true when setting other global parameters
>>> on init (such as "dpdk-socket-mem", for example). Changing the value at
>>> runtime is not supported, and requires restarting the vswitch
>>> daemon.
>>>
>>> The mempool sweep functionality is also replaced with the
>>> sweep functionality from OVS 2.9 found in commits
>>>
>>> c77f692 (netdev-dpdk: Free mempool only when no in-use mbufs.)
>>> a7fb0a4 (netdev-dpdk: Add mempool reuse/free debug.)
>>>
>>> As this patch is RFC there are a number of TO-DOs including adding a
>>> memory calculation section to the documentation for both models. This is
>>> expected to be completed in the v1 after RFC.
>>>
>>> Signed-off-by: Ian Stokes 
>>>
>>> ---
>>> v1 -> v2
>>> * Rebase to head of master.
>>> * Change global config option 'per-port-mp-enabled' to
>>> 'per-port-memory'.
>>>in commit message & documentation and code.
>>> * Specify in documentation that restart of daemon is only required if
>>> per
>>>port-port-memory is set after dpdk-init=true.
>>> * Return comment 'Contains all 'struct dpdk_mp's.' which was lost in
>>>previous refactor.
>>> * Improve comments regarding unique mempool names in the shared mempool
>>>usecase.
>>> * Check per_port_mp condition first when verifying if new mempool is
>>>required in netdev_dpdk_mempool_configure() for the shared mempool
>>>usecase.
>>> * Correctly return ret variable instead of 0 for function
>>>netdev_dpdk_mempool_configure().
>>> * Move VLOG_ERR regarding failure to create mempool for a device
>>> prior to
>>>dpdk_mp_create() returns.
>>> * Add VLOG_DBG message flagging that the number of mbufs could not be
>>>allocated and that it will be retried with half that amount.
>>> * Fix indentation of VLOG_ERR in netdev_dpdk_mempool_configure().
>>> * Handle EEXIST case for per port memory in function dpdk_mp_get() to
>>>avoid duplication of dpdk_mps, correctly set refcount and return
>>>correct dpdk_mp for the device to use.
>>> ---
>>>   Documentation/automake.mk|   1 +
>>>   Documentation/topics/dpdk/index.rst  |   1 +
>>>   Documentation/topics/dpdk/memory.rst |  67 
>>>   NEWS |   1 +
>>>   lib/dpdk-stub.c  |   6 +
>>>   lib/dpdk.c   |  12 ++
>>>   lib/dpdk.h   |   1 +
>>>   lib/netdev-dpdk.c| 298
>>> +++
>>>   vswitchd/vswitch.xml |  17 ++
>>>   9 files changed, 304 insertions(+), 100 deletions(-)
>>>   create mode 100644 Documentation/topics/dpdk/memory.rst
>>>
>>> diff --git a/Documentation/automake.mk b/Documentation/automake.mk
>>> index 2202df4..141b33d 100644
>>> --- a/Documentation/automake.mk
>>> +++ b/Documentation/automake.mk
>>> @@ -36,6 +36,7 @@ DOC_SOURCE = \
>>>   Documentation/topics/dpdk/index.rst \
>>>   Documentation/topics/dpdk/bridge.rst \
>>>   Documentation/topics/dpdk/jumbo-frames.rst \
>>> +Documentation/topics/dpdk/memory.rst \
>>>   Documentation/topics/dpdk/pdump.rst \
>>>   Documentation/topics/dpdk/p

Re: [ovs-dev] [PATCH] Utilities: Add the ovs_show_fdb command to gdb

2018-06-20 Thread Ben Pfaff

On Wed, Jun 20, 2018 at 11:04:03AM +0200, Eelco Chaudron wrote:
> This adds the ovs_show_fdb command:
> 
>   Usage: ovs_show_fdb { {dbg} {hash}}
> 
>: Optional bridge name, if not supplied FDB summary
>   information is displayed for all bridges.
>   dbg   : Will show structure address information
>   hash  : Will display the forwarding table using the hash
>   table, rather than the rlu list.

Thanks!  Applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath: Add meter action support.

2018-06-20 Thread Justin Pettit



> On Jun 20, 2018, at 9:59 AM, Gregory Rose  wrote:
> 
> On 6/19/2018 5:22 PM, Justin Pettit wrote:
>> From: Andy Zhou 
>> 
>> Upstream commit:
>> commit cd8a6c33693c1b89d2737ffdbf9611564e9ac907
>> Author: Andy Zhou 
>> Date:   Fri Nov 10 12:09:43 2017 -0800
>> 
>> openvswitch: Add meter action support
>> 
>> Implements OVS kernel meter action support.
>> 
>> Signed-off-by: Andy Zhou 
>> Signed-off-by: David S. Miller 
>> 
>> Signed-off-by: Justin Pettit 
> 
> LGTM
> 
> Reviewed-by: Greg Rose 
> Tested-by: Greg Rose 

Thanks.  I pushed this to master.

--Justin


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath: Fix compiler warning for HAVE_RHEL7_MAX_MTU.

2018-06-20 Thread Justin Pettit



> On Jun 20, 2018, at 9:22 AM, Gregory Rose  wrote:
> 
> On 6/19/2018 2:11 PM, Justin Pettit wrote:
>> Signed-off-by: Justin Pettit 
>> ---
>>  datapath/vport-internal_dev.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/datapath/vport-internal_dev.c b/datapath/vport-internal_dev.c
>> index 3fa86815c7fa..629965eab19f 100644
>> --- a/datapath/vport-internal_dev.c
>> +++ b/datapath/vport-internal_dev.c
>> @@ -169,7 +169,7 @@ static void do_setup(struct net_device *netdev)
>>#ifdef HAVE_NET_DEVICE_WITH_MAX_MTU
>>  netdev->max_mtu = ETH_MAX_MTU;
>> -#elif HAVE_RHEL7_MAX_MTU
>> +#elif defined(HAVE_RHEL7_MAX_MTU)
>>  netdev->extended->max_mtu = ETH_MAX_MTU;
>>  #endif
>>  netdev->netdev_ops = &internal_dev_netdev_ops;
> 
> I didn't bother to test - code inspection is enough to tell me this patch is 
> right.  Maybe add a fixes tag on push?
> 
> Reviewed-by: Greg Rose 

Thanks.  I added a "Fixes:" and pushed it to master.

--Justin


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath: Add meter action support.

2018-06-20 Thread Gregory Rose


On 6/19/2018 5:22 PM, Justin Pettit wrote:

From: Andy Zhou 

Upstream commit:
 commit cd8a6c33693c1b89d2737ffdbf9611564e9ac907
 Author: Andy Zhou 
 Date:   Fri Nov 10 12:09:43 2017 -0800

 openvswitch: Add meter action support

 Implements OVS kernel meter action support.

 Signed-off-by: Andy Zhou 
 Signed-off-by: David S. Miller 

Signed-off-by: Justin Pettit 
---
  NEWS  | 5 +++--
  datapath/actions.c| 6 ++
  datapath/datapath.h   | 1 +
  datapath/flow_netlink.c   | 6 ++
  datapath/linux/compat/include/linux/openvswitch.h | 2 +-
  5 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/NEWS b/NEWS
index 7f6589a46878..cd15a332c47e 100644
--- a/NEWS
+++ b/NEWS
@@ -19,8 +19,9 @@ Post-v2.9.0
   * New OpenFlow 1.0 extensions for group support.
   * Default selection method for select groups is now dp_hash with improved
 accuracy.
-   - Linux kernel 4.14
- * Add support for compiling OVS with the latest Linux 4.14 kernel
+   - Linux datapath
+ * Add support for compiling OVS with the latest Linux 4.14 kernel.
+ * Added support for meters.
 - ovn:
   * implemented icmp4/icmp6/tcp_reset actions in order to drop the packet
 and reply with a RST for TCP or ICMPv4/ICMPv6 unreachable message for
diff --git a/datapath/actions.c b/datapath/actions.c
index eab147617c8b..56b013601393 100644
--- a/datapath/actions.c
+++ b/datapath/actions.c
@@ -1341,6 +1341,12 @@ static int do_execute_actions(struct datapath *dp, 
struct sk_buff *skb,
case OVS_ACTION_ATTR_POP_NSH:
err = pop_nsh(skb, key);
break;
+
+   case OVS_ACTION_ATTR_METER:
+   if (ovs_meter_execute(dp, skb, key, nla_get_u32(a))) {
+   consume_skb(skb);
+   return 0;
+   }
}
  
  		if (unlikely(err)) {

diff --git a/datapath/datapath.h b/datapath/datapath.h
index 93c9ed505448..c38286df75c7 100644
--- a/datapath/datapath.h
+++ b/datapath/datapath.h
@@ -31,6 +31,7 @@
  #include "compat.h"
  #include "flow.h"
  #include "flow_table.h"
+#include "meter.h"
  #include "vport-internal_dev.h"
  
  #define DP_MAX_PORTS   USHRT_MAX

diff --git a/datapath/flow_netlink.c b/datapath/flow_netlink.c
index 1b7bad8fe2ab..bea525a5dfcb 100644
--- a/datapath/flow_netlink.c
+++ b/datapath/flow_netlink.c
@@ -92,6 +92,7 @@ static bool actions_may_change_flow(const struct nlattr 
*actions)
case OVS_ACTION_ATTR_SAMPLE:
case OVS_ACTION_ATTR_SET:
case OVS_ACTION_ATTR_SET_MASKED:
+   case OVS_ACTION_ATTR_METER:
default:
return true;
}
@@ -2853,6 +2854,7 @@ static int __ovs_nla_copy_actions(struct net *net, const 
struct nlattr *attr,
[OVS_ACTION_ATTR_POP_ETH] = 0,
[OVS_ACTION_ATTR_PUSH_NSH] = (u32)-1,
[OVS_ACTION_ATTR_POP_NSH] = 0,
+   [OVS_ACTION_ATTR_METER] = sizeof(u32),
};
const struct ovs_action_push_vlan *vlan;
int type = nla_type(a);
@@ -3038,6 +3040,10 @@ static int __ovs_nla_copy_actions(struct net *net, const 
struct nlattr *attr,
break;
}
  
+		case OVS_ACTION_ATTR_METER:

+   /* Non-existent meters are simply ignored.  */
+   break;
+
default:
OVS_NLERR(log, "Unknown Action type %d", type);
return -EINVAL;
diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index 5c1e2383f4f9..8e5f3b6fbfb1 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -934,12 +934,12 @@ enum ovs_action_attr {
OVS_ACTION_ATTR_CT_CLEAR, /* No argument. */
OVS_ACTION_ATTR_PUSH_NSH, /* Nested OVS_NSH_KEY_ATTR_*. */
OVS_ACTION_ATTR_POP_NSH,  /* No argument. */
+   OVS_ACTION_ATTR_METER, /* u32 meter number. */
  
  #ifndef __KERNEL__

OVS_ACTION_ATTR_TUNNEL_PUSH,   /* struct ovs_action_push_tnl*/
OVS_ACTION_ATTR_TUNNEL_POP,/* u32 port number. */
OVS_ACTION_ATTR_CLONE, /* Nested OVS_CLONE_ATTR_*.  */
-   OVS_ACTION_ATTR_METER, /* u32 meter number. */
  #endif
__OVS_ACTION_ATTR_MAX,/* Nothing past this will be accepted
   * from userspace. */


LGTM

Reviewed-by: Greg Rose 
Tested-by: Greg Rose 

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath: Fix compiler warning for HAVE_RHEL7_MAX_MTU.

2018-06-20 Thread Gregory Rose


On 6/19/2018 2:11 PM, Justin Pettit wrote:

Signed-off-by: Justin Pettit 
---
  datapath/vport-internal_dev.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/datapath/vport-internal_dev.c b/datapath/vport-internal_dev.c
index 3fa86815c7fa..629965eab19f 100644
--- a/datapath/vport-internal_dev.c
+++ b/datapath/vport-internal_dev.c
@@ -169,7 +169,7 @@ static void do_setup(struct net_device *netdev)
  
  #ifdef HAVE_NET_DEVICE_WITH_MAX_MTU

netdev->max_mtu = ETH_MAX_MTU;
-#elif HAVE_RHEL7_MAX_MTU
+#elif defined(HAVE_RHEL7_MAX_MTU)
netdev->extended->max_mtu = ETH_MAX_MTU;
  #endif
netdev->netdev_ops = &internal_dev_netdev_ops;


I didn't bother to test - code inspection is enough to tell me this 
patch is right.  Maybe add a fixes tag on push?


Reviewed-by: Greg Rose 

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Automated robotic reply. Re: ...

2018-06-20 Thread Aaron Conole

Justin Pettit  writes:

>> On Jun 20, 2018, at 8:47 AM, Ben Pfaff  wrote:
>> 
>>> On Wed, Jun 20, 2018 at 08:20:19AM -0700, Justin Pettit wrote:
>>> 
 On Jun 20, 2018, at 8:15 AM, Aaron Conole  wrote:
 
 0-day Robot  writes:
 
> Bleep bloop.  Greetings Justin Pettit, I am a robot and I have
> tried out your patch
> with message ID  <1529454160-88413-1-git-send-email-jpet...@ovn.org>
> Thanks for your contribution.
> 
> I encountered some error that I wasn't expecting.  See the details below.
> 
> 
> checkpatch:
> == Checking ".patch" ==
> ERROR: Too many signoffs; are you missing Co-authored-by lines?
> Lines checked: 118, Warnings: 0, Errors: 1
 
 I'll fix the sign off check in checkpatch.  It shouldn't flag on these
 kinds of patches.
 
 Sorry for the noise.
>>> 
>>> No problem.  Thanks for setting it up.  I agree that it shouldn't flag
>>> on this issue, however, the bigger concern I have is that the warning
>>> seems to be separated from the file names, which is a bit confusing.
>>> And, I imagine it would be very confusing if someone had multiple
>>> patches flagged, since it wouldn't be clear which error list applied
>>> to which patch.
>> 
>> What file names?  Sign-offs aren't associated with files.
>
> Sorry, I meant patch name. 

I'll work on the job a bit more.  I've made it manually triggered.  I'll
try and fix a few flaws I've found (mostly false positives).

Thanks for not flaming me :)

> —Justin
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Automated robotic reply. Re: ...

2018-06-20 Thread Justin Pettit


> On Jun 20, 2018, at 8:47 AM, Ben Pfaff  wrote:
> 
>> On Wed, Jun 20, 2018 at 08:20:19AM -0700, Justin Pettit wrote:
>> 
>>> On Jun 20, 2018, at 8:15 AM, Aaron Conole  wrote:
>>> 
>>> 0-day Robot  writes:
>>> 
 Bleep bloop.  Greetings Justin Pettit, I am a robot and I have tried out 
 your patch
 with message ID  <1529454160-88413-1-git-send-email-jpet...@ovn.org>
 Thanks for your contribution.
 
 I encountered some error that I wasn't expecting.  See the details below.
 
 
 checkpatch:
 == Checking ".patch" ==
 ERROR: Too many signoffs; are you missing Co-authored-by lines?
 Lines checked: 118, Warnings: 0, Errors: 1
>>> 
>>> I'll fix the sign off check in checkpatch.  It shouldn't flag on these
>>> kinds of patches.
>>> 
>>> Sorry for the noise.
>> 
>> No problem.  Thanks for setting it up.  I agree that it shouldn't flag
>> on this issue, however, the bigger concern I have is that the warning
>> seems to be separated from the file names, which is a bit confusing.
>> And, I imagine it would be very confusing if someone had multiple
>> patches flagged, since it wouldn't be clear which error list applied
>> to which patch.
> 
> What file names?  Sign-offs aren't associated with files.

Sorry, I meant patch name. 

—Justin


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Automated robotic reply. Re: ...

2018-06-20 Thread Ben Pfaff

On Wed, Jun 20, 2018 at 08:20:19AM -0700, Justin Pettit wrote:
> 
> > On Jun 20, 2018, at 8:15 AM, Aaron Conole  wrote:
> > 
> > 0-day Robot  writes:
> > 
> >> Bleep bloop.  Greetings Justin Pettit, I am a robot and I have tried out 
> >> your patch
> >> with message ID  <1529454160-88413-1-git-send-email-jpet...@ovn.org>
> >> Thanks for your contribution.
> >> 
> >> I encountered some error that I wasn't expecting.  See the details below.
> >> 
> >> 
> >> checkpatch:
> >> == Checking ".patch" ==
> >> ERROR: Too many signoffs; are you missing Co-authored-by lines?
> >> Lines checked: 118, Warnings: 0, Errors: 1
> > 
> > I'll fix the sign off check in checkpatch.  It shouldn't flag on these
> > kinds of patches.
> > 
> > Sorry for the noise.
> 
> No problem.  Thanks for setting it up.  I agree that it shouldn't flag
> on this issue, however, the bigger concern I have is that the warning
> seems to be separated from the file names, which is a bit confusing.
> And, I imagine it would be very confusing if someone had multiple
> patches flagged, since it wouldn't be clear which error list applied
> to which patch.

What file names?  Sign-offs aren't associated with files.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Automated robotic reply. Re: ...

2018-06-20 Thread Justin Pettit

> On Jun 20, 2018, at 8:15 AM, Aaron Conole  wrote:
> 
> 0-day Robot  writes:
> 
>> Bleep bloop.  Greetings Justin Pettit, I am a robot and I have tried out 
>> your patch
>> with message ID  <1529454160-88413-1-git-send-email-jpet...@ovn.org>
>> Thanks for your contribution.
>> 
>> I encountered some error that I wasn't expecting.  See the details below.
>> 
>> 
>> checkpatch:
>> == Checking ".patch" ==
>> ERROR: Too many signoffs; are you missing Co-authored-by lines?
>> Lines checked: 118, Warnings: 0, Errors: 1
> 
> I'll fix the sign off check in checkpatch.  It shouldn't flag on these
> kinds of patches.
> 
> Sorry for the noise.

No problem.  Thanks for setting it up.  I agree that it shouldn't flag on this 
issue, however, the bigger concern I have is that the warning seems to be 
separated from the file names, which is a bit confusing.  And, I imagine it 
would be very confusing if someone had multiple patches flagged, since it 
wouldn't be clear which error list applied to which patch.

--Justin

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Automated robotic reply. Re: ...

2018-06-20 Thread Aaron Conole

0-day Robot  writes:

> Bleep bloop.  Greetings Justin Pettit, I am a robot and I have tried out your 
> patch
> with message ID  <1529454160-88413-1-git-send-email-jpet...@ovn.org>
> Thanks for your contribution.
>
> I encountered some error that I wasn't expecting.  See the details below.
>
>
> checkpatch:
> == Checking ".patch" ==
> ERROR: Too many signoffs; are you missing Co-authored-by lines?
> Lines checked: 118, Warnings: 0, Errors: 1

I'll fix the sign off check in checkpatch.  It shouldn't flag on these
kinds of patches.

Sorry for the noise.

>
> Please check this out.  If you feel there has been an error, please email me 
> back.
>
> Thanks,
> 0-day Robot
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Automated robotic reply. Re: ...

2018-06-20 Thread 0-day Robot

Bleep bloop.  Greetings Justin Pettit, I am a robot and I have tried out your 
patch
with message ID  <1529454160-88413-1-git-send-email-jpet...@ovn.org>
Thanks for your contribution.

I encountered some error that I wasn't expecting.  See the details below.


checkpatch:
== Checking ".patch" ==
ERROR: Too many signoffs; are you missing Co-authored-by lines?
Lines checked: 118, Warnings: 0, Errors: 1


Please check this out.  If you feel there has been an error, please email me 
back.

Thanks,
0-day Robot
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Automated robotic reply. Re: ...

2018-06-20 Thread 0-day Robot

Bleep bloop.  Greetings Justin Pettit, I am a robot and I have tried out your 
patch
with message ID  <1529442677-70672-1-git-send-email-jpet...@ovn.org>
Thanks for your contribution.

I encountered some error that I wasn't expecting.  See the details below.


git-am:
Applying: datapath: Fix compiler warning for HAVE_RHEL7_MAX_MTU.


Please check this out.  If you feel there has been an error, please email me 
back.

Thanks,
0-day Robot
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Incorporación y desarrollo de personas

2018-06-20 Thread Gestión de Recursos Humanos





  






 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
 


 
 
 
 
 
 

---
Este correo electrónico ha sido comprobado en busca de virus por AVG.
http://www.avg.com
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OVS (master) + DPDK(17.11) + multi-queue

2018-06-20 Thread Loftus, Ciara

> 
> Hi,
> 
> 
> On Tue, Jun 19, 2018 at 12:27 AM Ilya Maximets 
> wrote:
> 
> > Hi,
> > According to your log, your NIC has limited size of tx queues:
> >
> >   2018-06-19T04:34:46.106Z|00089|dpdk|ERR|PMD: Unsupported size of TX
> queue
> >(max size: 1024)
> >
> > This means that you have to configure 'n_txq_desc' <= 1024 in order to
> > configure your NIC properly. OVS uses 2048 by default and this is causes
> > device configuration failure.
> >
> > Try this:
> >
> > ovs-vsctl set interface eth1 options:n_txq_desc=1024
> >
> > It also likely that you will have to configure the same value for
> > 'n_rxq_desc'.
> >
> >
> Thank you. It was indeed no. queue descriptors issue. Modifying the config
> to 1024 fixed it.
> 
> I am using 'pdump/pcap' features in dpdk for packet capture with OVS-DPDK
> and currently it doesn't seem to work. I used following link
> 
> https://software.intel.com/en-us/articles/dpdk-pdump-in-open-vswitch-
> with-dpdk
> 
> OVS is linked to DPDK 17.11.2 which has pdump library built. OVS has pdump
> server socket file created
> 
> ls -l /usr/local/var/run/openvswitch/
> total 8
> ...
> srwxr-x--- 1 root root 0 Jun 19 19:26 pdump_server_socket
> srwxr-x--- 1 root root 0 Jun 19 19:26 vhost-user-1
> srwxr-x--- 1 root root 0 Jun 19 19:26 vhost-user-2
> 
> ./x86_64-native-linuxapp-gcc/build/app/pdump/dpdk-pdump -- --pdump
> port=1,queue=*,rx-dev=/tmp/pkts.pcap
> --server-socket-path=/usr/local/var/run/openvswitch
> EAL: Detected 8 lcore(s)
> PANIC in rte_eal_config_attach():
> *Cannot open '/var/run/.rte_config' for rte_mem_config*
> 6: [./x86_64-native-linuxapp-gcc/build/app/pdump/dpdk-
> pdump(_start+0x29)
> [0x4472e9]]
> 5: [/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)
> [0x7ff0ae7ba830]]
> 4: [./x86_64-native-linuxapp-gcc/build/app/pdump/dpdk-
> pdump(main+0x155)
> [0x44aa76]]
> 3:
> [./x86_64-native-linuxapp-gcc/build/app/pdump/dpdk-
> pdump(rte_eal_init+0xc7d)
> [0x49ef0d]]
> 2:
> [./x86_64-native-linuxapp-gcc/build/app/pdump/dpdk-
> pdump(__rte_panic+0xc3)
> [0x43ebb3]]
> 1:
> [./x86_64-native-linuxapp-gcc/build/app/pdump/dpdk-
> pdump(rte_dump_stack+0x2b)
> [0x4a573b]]
> Aborted
> 
> Anything I am missing?

Hi,

I can't reproduce your pdump issue. For me using the same command it works ok.
Does /var/run/.rte_config exist and do you have sufficient permissions to 
access that file as the user executing the pdump app?
http://dpdk.readthedocs.io/en/v17.11/prog_guide/multi_proc_support.html#running-multiple-independent-dpdk-applications
 may also help.

Thanks,
Ciara

> 
> Thanks.
> 
> 
> > Note that OVS manages TX queues itself and it will try to allocate
> > separate TX queue for each PMD thread + 1 for non-PMD threads. So,
> > it's kind of impossible to force it to configure only one TX queue
> > in case HW supports multiqueue.
> >
> > > Hi,
> > >
> > > I am using above configuration on my testbed and when I try to add a
> port
> > > which is bound to igb_uio, I see following errors due to Tx queue
> > > configuration. I just want to use single Tx and Rx queue for my testing.
> > I
> > > looked at Documentation/intro/install/dpdk.rst, i see only "DPDK Physical
> > > Port Rx Queues" and nothing for "Tx Queues". Kindly let me know how
> can I
> > > use single tx/rx queues and if I have to use multiple Tx queues what
> > > configuration changes I need to do?
> > >
> > > ovs logs==
> > > 2018-06-19T04:33:23.720Z|00075|bridge|INFO|ovs-vswitchd (Open
> vSwitch)
> > > 2.9.90
> > > 2018-06-19T04:33:32.735Z|00076|memory|INFO|127688 kB peak resident
> set
> > size
> > > after 10.1 seconds
> > > 2018-06-19T04:33:32.735Z|00077|memory|INFO|handlers:5 ports:1
> > > revalidators:3 rules:5
> > > 2018-06-19T04:33:40.857Z|00078|rconn|INFO|br0<->unix#0: connected
> > > 2018-06-19T04:33:40.858Z|00079|rconn|INFO|br0<->unix#1: connected
> > > 2018-06-19T04:33:40.859Z|00080|rconn|INFO|br0<->unix#2: connected
> > > 2018-06-19T04:34:46.094Z|00081|dpdk|INFO|EAL: PCI device
> :00:06.0 on
> > > NUMA socket 0
> > > 2018-06-19T04:34:46.094Z|00082|dpdk|INFO|EAL:   probe driver:
> 1d0f:ec20
> > > net_ena
> > > 2018-06-19T04:34:46.095Z|00083|dpdk|INFO|PMD: eth_ena_dev_init():
> > > Initializing 0:0:6.0
> > > 2018-06-19T04:34:46.095Z|00084|netdev_dpdk|INFO|Device
> ':00:06.0'
> > > attached to DPDK
> > > 2018-06-19T04:34:46.099Z|00085|dpif_netdev|INFO|PMD thread on
> numa_id: 0,
> > > core id:  0 created.
> > > 2018-06-19T04:34:46.099Z|00086|dpif_netdev|INFO|There are 1 pmd
> threads
> > on
> > > numa node 0
> > > 2018-06-19T04:34:46.105Z|00087|netdev_dpdk|WARN|Rx checksum
> offload is
> > not
> > > supported on port 0
> > > 2018-06-19T04:34:46.105Z|00088|dpdk|INFO|PMD: Set MTU: 1500
> > > 2018-06-19T04:34:46.106Z|00089|dpdk|ERR|PMD: Unsupported size of
> TX queue
> > > (max size: 1024)
> > > 2018-06-19T04:34:46.106Z|00090|netdev_dpdk|INFO|Interface eth1
> unable to
> > > setup txq(0): Invalid argument
> > > 2018-06-

Re: [ovs-dev] 64Byte packet performance regression on 2.9 from 2.7

2018-06-20 Thread Shahaji Bhosle via dev

Thanks Ilya,
 Sorry for the confusion with the number, we used to get some different
numbers on both ports so were recording it per port. You have to compare it
with the two port number

CPU mask Mpps
17.11 testpmd 6 queue 0xfe 21.5 + 21.5
OvS 2.9+DPDK17.11 6 queue 0xfe 15.5 + 15.5
16.11 testpmd 6 queue 0xfe 21.5 + 21.5
OvS 2.7+DPDK16.11 6 queue 0xfe 17.4+17.4
Thanks, Shahaji

On Wed, Jun 20, 2018 at 8:34 AM, Ilya Maximets 
wrote:

> Ok, I'll look at the data later.
>
> But your testpmd results are much lower than OVS results. 21.5Mpps for
> testpmd
> versus 33.8Mpps for OVS. OVS should work slower than testpmd, because it
> performs
> a lot of parsing and processing while testpmd does not.
> You probably tested testpmd in deifferent environment or allocated less
> amount
> of resources for PMD htreads. Could you please recheck?
>
> What is your OVS configuration (pmd-cpu-mask, n_rxqs etc.)?
> And what is your testpmd command-line?
>
> On 20.06.2018 14:54, Shahaji Bhosle wrote:
> > Thanks Ilya,
> > Attaching the two perf reports...We did run testpmd on its own, there
> were no red flags there. In some of the cases like flowgen 17.11 performs
> much better than 16.11, but for the macswap case, the numbers are below.
> Let me know if you cannot see the attached perf reports. I can just cut and
> paste them in the email if attachment does not work. Sorry I am not sure I
> can post these on any outside servers. Let me know
> > Thanks, Shahaji
> >
> > *DPDK on Maia (macswap)*  *Rings* *Mpps*  *Cycles/Packet*
> > 17.11 testpmd 6 queue 21.5 + 21.5 60
> >   1 queue 10.4+10.4   14
> > 16.11 testpmd 6 queue 21.5 + 21.5 60
> >   1 queue 10.4+10.4   14
> >
> >
> > On Wed, Jun 20, 2018 at 4:52 AM, Ilya Maximets  > wrote:
> >
> > Looking at your perf stats I see following:
> >
> > OVS 2.7:
> >
> >   ??.??% - dp_netdev_process_rxq_port
> >   |-- 93.36% - dp_netdev_input
> >   |-- ??.??% - netdev_rxq_recv
> >
> > OVS 2.9:
> >
> >   99.69% - dp_netdev_process_rxq_port
> >   |-- 79.45% - dp_netdev_input
> >   |-- 11.26% - dp_netdev_pmd_flush_output_packets
> >   |-- ??.??% - netdev_rxq_recv
> >
> > Could you please fill the missed (??.??) values?
> > This data I got from the picture attached to the previous mail, but
> pictures
> > are still not allowed in mail-list (i.e. stripped). It'll be good if
> you can
> > upload your raw data to some external resource and post the link
> here.
> >
> > Anyway, from the data I have, I can see that total sum of time spent
> in
> > "dp_netdev_input" and "dp_netdev_pmd_flush_output_packets" for 2.9
> is 90.71%,
> > which is less then 93.36% spent for 2.7. This means that processing
> + sending
> > become even faster or remains with the approximately same
> performance.
> > We definitely need all the missed values to be sure, but it seems
> that the
> > "netdev_rxq_recv()" could be the issue.
> >
> > To check if DPDK itself causes the performance regression, I'd ask
> you
> > to check pure PHY-PHY test with testpmd app from DPDK 16.11 and DPDK
> 17.11.
> > Maybe it's the performance issue with bnxt driver that you're using.
> > There was too many changes in that driver:
> >
> >   30 files changed, 17189 insertions(+), 3358 deletions(-)
> >
> > Best regards, Ilya Maximets.
> >
> > On 20.06.2018 01:18, Shahaji Bhosle wrote:
> > > Hi Ilya,
> > > This issue is a release blocker for us, just wanted to check check
> if you need more details from us? Anything to expedite or root cause the
> problem we can help
> > > Please let us know
> > > Thanks Shahaji
> > >
> > > On Mon, Jun 18, 2018 at 10:20 AM Shahaji Bhosle <
> shahaji.bho...@broadcom.com   shahaji.bho...@broadcom.com >> wrote:
> > >
> > > Thanks Ilya, I will look at the commit, but not sure now how
> to tell how much real work is being done, I would have liked polling cycles
> to be treated as before and not towards packet processing. That does
> explain, as long as there are packets on the wire we are always 100%,
> basically cannot tell how efficiently the CPUs are being used.
> > > Thanks, Shahaji
> > >
> > > On Mon, Jun 18, 2018 at 10:07 AM, Ilya Maximets <
> i.maxim...@samsung.com   i.maxim...@samsung.com >> wrote:
> > >
> > > Thanks for the data.
> > >
> > > I have to note additionally that the meaning of
> "processing cycles"
> > > significantly changed since the following commit:
> > >
> > > commit a2ac666d5265c01661e189caac321d962f54649f
> > > Author: Ciara Loftus  ciara.lof...@

Re: [ovs-dev] [RFC PATCH v2 1/1] dpdk: Support both shared and per port mempools.

2018-06-20 Thread Ian Stokes


On 6/19/2018 12:46 PM, Kevin Traynor wrote:

On 06/19/2018 12:16 PM, Kevin Traynor wrote:

On 06/19/2018 12:11 PM, Kevin Traynor wrote:

+if (per_port_mp && rte_errno == EEXIST) {
+LIST_FOR_EACH (next, list_node, &dpdk_mp_list) {
+if (dmp->mp == next->mp) {
+rte_free(dmp);
+dmp = next;
+dmp->refcount = 1;
+}
+}
+}
+else {
+ovs_list_push_back(&dpdk_mp_list, &dmp->list_node);
+}

I think you need to increment refcount and use the safe list option. How
about



Actually no, you don't need the safe list option, as it's the dmp that
is being freed


I obviously misread this (or wasn't concentrating enough), you do still
need the dmp = next as well.



Sure, I've responded in the original thread that I'll take this 
approach. I'm not against using the second safe list but wanted to keep 
it to 1 list if possible.


Ian



if (rte_errno == EEXIST) {
 LIST_FOR_EACH_SAFE (next, list_node, &dpdk_mp_list) {
 if (dmp->mp == next->mp) {
 next->refcount++;
 rte_free(dmp);
 break;
 }
 }
} else {
 dmp->refcount++;
 ovs_list_push_back(&dpdk_mp_list, &dmp->list_node);
}







___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC PATCH v2 1/1] dpdk: Support both shared and per port mempools.

2018-06-20 Thread Ian Stokes


On 6/19/2018 12:11 PM, Kevin Traynor wrote:

On 06/11/2018 05:37 PM, Ian Stokes wrote:

This commit re-introduces the concept of shared mempools as the default
memory model for DPDK devices. Per port mempools are still available but
must be enabled explicitly by a user.



Hi Ian, thanks for v2, comments below


Thanks for the review Kevin, comments inline.




OVS previously used a shared mempool model for ports with the same MTU
and socket configuration. This was replaced by a per port mempool model
to address issues flagged by users such as:

https://mail.openvswitch.org/pipermail/ovs-discuss/2016-September/042560.html

However the per port model potentially requires an increase in memory
resource requirements to support the same number of ports and configuration
as the shared port model.

This is considered a blocking factor for current deployments of OVS
when upgrading to future OVS releases as a user may have to redimension
memory for the same deployment configuration. This may not be possible for
users.

This commit resolves the issue by re-introducing shared mempools as
the default memory behaviour in OVS DPDK but also refactors the memory
configuration code to allow for per port mempools.

This patch adds a new global config option, per-port-mp, that


s/per-port-mp/per-port-memory/


Apologies, I spotted a few of these 'per-port-mp' myself, I believe it's 
in the documentation as well. I have them fixed for the next revision.





controls the enablement of per port mempools for DPDK devices.

 ovs-vsctl set Open_vSwitch . other_config:per-port-memory=true

This value defaults to false; to enable per port memory support,
this field should be set to true when setting other global parameters
on init (such as "dpdk-socket-mem", for example). Changing the value at
runtime is not supported, and requires restarting the vswitch
daemon.

The mempool sweep functionality is also replaced with the
sweep functionality from OVS 2.9 found in commits

c77f692 (netdev-dpdk: Free mempool only when no in-use mbufs.)
a7fb0a4 (netdev-dpdk: Add mempool reuse/free debug.)

As this patch is RFC there are a number of TO-DOs including adding a
memory calculation section to the documentation for both models. This is
expected to be completed in the v1 after RFC.

Signed-off-by: Ian Stokes 

---
v1 -> v2
* Rebase to head of master.
* Change global config option 'per-port-mp-enabled' to 'per-port-memory'.
   in commit message & documentation and code.
* Specify in documentation that restart of daemon is only required if per
   port-port-memory is set after dpdk-init=true.
* Return comment 'Contains all 'struct dpdk_mp's.' which was lost in
   previous refactor.
* Improve comments regarding unique mempool names in the shared mempool
   usecase.
* Check per_port_mp condition first when verifying if new mempool is
   required in netdev_dpdk_mempool_configure() for the shared mempool
   usecase.
* Correctly return ret variable instead of 0 for function
   netdev_dpdk_mempool_configure().
* Move VLOG_ERR regarding failure to create mempool for a device prior to
   dpdk_mp_create() returns.
* Add VLOG_DBG message flagging that the number of mbufs could not be
   allocated and that it will be retried with half that amount.
* Fix indentation of VLOG_ERR in netdev_dpdk_mempool_configure().
* Handle EEXIST case for per port memory in function dpdk_mp_get() to
   avoid duplication of dpdk_mps, correctly set refcount and return
   correct dpdk_mp for the device to use.
---
  Documentation/automake.mk|   1 +
  Documentation/topics/dpdk/index.rst  |   1 +
  Documentation/topics/dpdk/memory.rst |  67 
  NEWS |   1 +
  lib/dpdk-stub.c  |   6 +
  lib/dpdk.c   |  12 ++
  lib/dpdk.h   |   1 +
  lib/netdev-dpdk.c| 298 +++
  vswitchd/vswitch.xml |  17 ++
  9 files changed, 304 insertions(+), 100 deletions(-)
  create mode 100644 Documentation/topics/dpdk/memory.rst

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 2202df4..141b33d 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -36,6 +36,7 @@ DOC_SOURCE = \
Documentation/topics/dpdk/index.rst \
Documentation/topics/dpdk/bridge.rst \
Documentation/topics/dpdk/jumbo-frames.rst \
+   Documentation/topics/dpdk/memory.rst \
Documentation/topics/dpdk/pdump.rst \
Documentation/topics/dpdk/phy.rst \
Documentation/topics/dpdk/pmd.rst \
diff --git a/Documentation/topics/dpdk/index.rst 
b/Documentation/topics/dpdk/index.rst
index 181f61a..cf24a7b 100644
--- a/Documentation/topics/dpdk/index.rst
+++ b/Documentation/topics/dpdk/index.rst
@@ -40,3 +40,4 @@ The DPDK Datapath
 /topics/dpdk/qos
 /topics/dpdk/pdump
 /topics/dpdk/jumbo-frames
+   /topics/dpdk/memory
diff --git a/Documentation/topics/dpdk/memory.r

Re: [ovs-dev] 64Byte packet performance regression on 2.9 from 2.7

2018-06-20 Thread Ilya Maximets

Ok, I'll look at the data later.

But your testpmd results are much lower than OVS results. 21.5Mpps for testpmd
versus 33.8Mpps for OVS. OVS should work slower than testpmd, because it 
performs
a lot of parsing and processing while testpmd does not.
You probably tested testpmd in deifferent environment or allocated less amount
of resources for PMD htreads. Could you please recheck?

What is your OVS configuration (pmd-cpu-mask, n_rxqs etc.)?
And what is your testpmd command-line?

On 20.06.2018 14:54, Shahaji Bhosle wrote:
> Thanks Ilya,
> Attaching the two perf reports...We did run testpmd on its own, there were no 
> red flags there. In some of the cases like flowgen 17.11 performs much better 
> than 16.11, but for the macswap case, the numbers are below. Let me know if 
> you cannot see the attached perf reports. I can just cut and paste them in 
> the email if attachment does not work. Sorry I am not sure I can post these 
> on any outside servers. Let me know
> Thanks, Shahaji
> 
> *DPDK on Maia (macswap)*  *Rings* *Mpps*  *Cycles/Packet*
> 17.11 testpmd 6 queue 21.5 + 21.5 60
>   1 queue 10.4+10.4   14
> 16.11 testpmd 6 queue 21.5 + 21.5 60
>   1 queue 10.4+10.4   14
> 
> 
> On Wed, Jun 20, 2018 at 4:52 AM, Ilya Maximets  > wrote:
> 
> Looking at your perf stats I see following:
> 
> OVS 2.7:
> 
>   ??.??% - dp_netdev_process_rxq_port
>   |-- 93.36% - dp_netdev_input
>   |-- ??.??% - netdev_rxq_recv
> 
> OVS 2.9:
> 
>   99.69% - dp_netdev_process_rxq_port
>   |-- 79.45% - dp_netdev_input
>   |-- 11.26% - dp_netdev_pmd_flush_output_packets
>   |-- ??.??% - netdev_rxq_recv
> 
> Could you please fill the missed (??.??) values?
> This data I got from the picture attached to the previous mail, but 
> pictures
> are still not allowed in mail-list (i.e. stripped). It'll be good if you 
> can
> upload your raw data to some external resource and post the link here.
> 
> Anyway, from the data I have, I can see that total sum of time spent in
> "dp_netdev_input" and "dp_netdev_pmd_flush_output_packets" for 2.9 is 
> 90.71%,
> which is less then 93.36% spent for 2.7. This means that processing + 
> sending
> become even faster or remains with the approximately same performance.
> We definitely need all the missed values to be sure, but it seems that the
> "netdev_rxq_recv()" could be the issue.
> 
> To check if DPDK itself causes the performance regression, I'd ask you
> to check pure PHY-PHY test with testpmd app from DPDK 16.11 and DPDK 
> 17.11.
> Maybe it's the performance issue with bnxt driver that you're using.
> There was too many changes in that driver:
> 
>   30 files changed, 17189 insertions(+), 3358 deletions(-)
> 
> Best regards, Ilya Maximets.
> 
> On 20.06.2018 01:18, Shahaji Bhosle wrote:
> > Hi Ilya,
> > This issue is a release blocker for us, just wanted to check check if 
> you need more details from us? Anything to expedite or root cause the problem 
> we can help 
> > Please let us know 
> > Thanks Shahaji 
> > 
> > On Mon, Jun 18, 2018 at 10:20 AM Shahaji Bhosle 
> mailto:shahaji.bho...@broadcom.com> 
> >> 
> wrote:
> > 
> >     Thanks Ilya, I will look at the commit, but not sure now how to 
> tell how much real work is being done, I would have liked polling cycles to 
> be treated as before and not towards packet processing. That does explain, as 
> long as there are packets on the wire we are always 100%, basically cannot 
> tell how efficiently the CPUs are being used.
> >     Thanks, Shahaji
> > 
> >     On Mon, Jun 18, 2018 at 10:07 AM, Ilya Maximets 
> mailto:i.maxim...@samsung.com> 
> >> wrote:
> > 
> >         Thanks for the data.
> > 
> >         I have to note additionally that the meaning of "processing 
> cycles"
> >         significantly changed since the following commit:
> > 
> >             commit a2ac666d5265c01661e189caac321d962f54649f
> >             Author: Ciara Loftus    >>
> >             Date:   Mon Feb 20 12:53:00 2017 +
> > 
> >                 dpif-netdev: Change definitions of 'idle' & 
> 'processing' cycles
> > 
> >                 Instead of counting all polling cycles as processing 
> cycles, only count
> >                 the cycles where packets were received from the polling.
> > 
> >         This could explain the difference in "PMD Processing Cycles" 
> column,
> >         because successful "POLLING" cycles are now included into

Re: [ovs-dev] OVS (master) + DPDK(17.11) + multi-queue

2018-06-20 Thread Ilya Maximets

On 19.06.2018 22:41, Ravi Kerur wrote:
> Hi,
> 
> 
> On Tue, Jun 19, 2018 at 12:27 AM Ilya Maximets  > wrote:
> 
> Hi,
> According to your log, your NIC has limited size of tx queues:
> 
>   2018-06-19T04:34:46.106Z|00089|dpdk|ERR|PMD: Unsupported size of TX 
> queue
>                                                (max size: 1024)
> 
> This means that you have to configure 'n_txq_desc' <= 1024 in order to
> configure your NIC properly. OVS uses 2048 by default and this is causes
> device configuration failure.
> 
> Try this:
> 
>     ovs-vsctl set interface eth1 options:n_txq_desc=1024
> 
> It also likely that you will have to configure the same value for 
> 'n_rxq_desc'.
> 
> 
> Thank you. It was indeed no. queue descriptors issue. Modifying the config to 
> 1024 fixed it.
> 
> I am using 'pdump/pcap' features in dpdk for packet capture with OVS-DPDK and 
> currently it doesn't seem to work. I used following link
> 
> https://software.intel.com/en-us/articles/dpdk-pdump-in-open-vswitch-with-dpdk
> 
> OVS is linked to DPDK 17.11.2 which has pdump library built. OVS has pdump 
> server socket file created
> 
> ls -l /usr/local/var/run/openvswitch/
> total 8
> ...
> srwxr-x--- 1 root root 0 Jun 19 19:26 pdump_server_socket
> srwxr-x--- 1 root root 0 Jun 19 19:26 vhost-user-1
> srwxr-x--- 1 root root 0 Jun 19 19:26 vhost-user-2
> 
> ./x86_64-native-linuxapp-gcc/build/app/pdump/dpdk-pdump -- --pdump 
> port=1,queue=*,rx-dev=/tmp/pkts.pcap 
> --server-socket-path=/usr/local/var/run/openvswitch
> EAL: Detected 8 lcore(s)
> PANIC in rte_eal_config_attach():
> *Cannot open '/var/run/.rte_config' for rte_mem_config*
> 6: [./x86_64-native-linuxapp-gcc/build/app/pdump/dpdk-pdump(_start+0x29) 
> [0x4472e9]]
> 5: [/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7ff0ae7ba830]]
> 4: [./x86_64-native-linuxapp-gcc/build/app/pdump/dpdk-pdump(main+0x155) 
> [0x44aa76]]
> 3: 
> [./x86_64-native-linuxapp-gcc/build/app/pdump/dpdk-pdump(rte_eal_init+0xc7d) 
> [0x49ef0d]]
> 2: [./x86_64-native-linuxapp-gcc/build/app/pdump/dpdk-pdump(__rte_panic+0xc3) 
> [0x43ebb3]]
> 1: 
> [./x86_64-native-linuxapp-gcc/build/app/pdump/dpdk-pdump(rte_dump_stack+0x2b) 
> [0x4a573b]]
> Aborted
> 
> Anything I am missing?


I never used pdump with OVS, actually.
I'd personally suggest you to try "ovs-tcpdump" instead.


> 
> Thanks.
> 
> 
> Note that OVS manages TX queues itself and it will try to allocate
> separate TX queue for each PMD thread + 1 for non-PMD threads. So,
> it's kind of impossible to force it to configure only one TX queue
> in case HW supports multiqueue.
> 
> > Hi,
> >
> > I am using above configuration on my testbed and when I try to add a 
> port
> > which is bound to igb_uio, I see following errors due to Tx queue
> > configuration. I just want to use single Tx and Rx queue for my 
> testing. I
> > looked at Documentation/intro/install/dpdk.rst, i see only "DPDK 
> Physical
> > Port Rx Queues" and nothing for "Tx Queues". Kindly let me know how can 
> I
> > use single tx/rx queues and if I have to use multiple Tx queues what
> > configuration changes I need to do?
> >
> > ovs logs==
> > 2018-06-19T04:33:23.720Z|00075|bridge|INFO|ovs-vswitchd (Open vSwitch)
> > 2.9.90
> > 2018-06-19T04:33:32.735Z|00076|memory|INFO|127688 kB peak resident set 
> size
> > after 10.1 seconds
> > 2018-06-19T04:33:32.735Z|00077|memory|INFO|handlers:5 ports:1
> > revalidators:3 rules:5
> > 2018-06-19T04:33:40.857Z|00078|rconn|INFO|br0<->unix#0: connected
> > 2018-06-19T04:33:40.858Z|00079|rconn|INFO|br0<->unix#1: connected
> > 2018-06-19T04:33:40.859Z|00080|rconn|INFO|br0<->unix#2: connected
> > 2018-06-19T04:34:46.094Z|00081|dpdk|INFO|EAL: PCI device :00:06.0 on
> > NUMA socket 0
> > 2018-06-19T04:34:46.094Z|00082|dpdk|INFO|EAL:   probe driver: 1d0f:ec20
> > net_ena
> > 2018-06-19T04:34:46.095Z|00083|dpdk|INFO|PMD: eth_ena_dev_init():
> > Initializing 0:0:6.0
> > 2018-06-19T04:34:46.095Z|00084|netdev_dpdk|INFO|Device ':00:06.0'
> > attached to DPDK
> > 2018-06-19T04:34:46.099Z|00085|dpif_netdev|INFO|PMD thread on numa_id: 
> 0,
> > core id:  0 created.
> > 2018-06-19T04:34:46.099Z|00086|dpif_netdev|INFO|There are 1 pmd threads 
> on
> > numa node 0
> > 2018-06-19T04:34:46.105Z|00087|netdev_dpdk|WARN|Rx checksum offload is 
> not
> > supported on port 0
> > 2018-06-19T04:34:46.105Z|00088|dpdk|INFO|PMD: Set MTU: 1500
> > 2018-06-19T04:34:46.106Z|00089|dpdk|ERR|PMD: Unsupported size of TX 
> queue
> > (max size: 1024)
> > 2018-06-19T04:34:46.106Z|00090|netdev_dpdk|INFO|Interface eth1 unable to
> > setup txq(0): Invalid argument
> > 2018-06-19T04:34:46.106Z|00091|netdev_dpdk|ERR|Interface eth1(rxq:1 
> txq:2
> > lsc interrupt mode:false) configure error: I

Re: [ovs-dev] 64Byte packet performance regression on 2.9 from 2.7

2018-06-20 Thread Shahaji Bhosle via dev

Thanks Ilya,
Attaching the two perf reports...We did run testpmd on its own, there were
no red flags there. In some of the cases like flowgen 17.11 performs much
better than 16.11, but for the macswap case, the numbers are below. Let me
know if you cannot see the attached perf reports. I can just cut and paste
them in the email if attachment does not work. Sorry I am not sure I can
post these on any outside servers. Let me know
Thanks, Shahaji

*DPDK on Maia (macswap)* *Rings* *Mpps* *Cycles/Packet*
17.11 testpmd 6 queue 21.5 + 21.5 60
1 queue 10.4+10.4 14
16.11 testpmd 6 queue 21.5 + 21.5 60
1 queue 10.4+10.4 14

On Wed, Jun 20, 2018 at 4:52 AM, Ilya Maximets 
wrote:

> Looking at your perf stats I see following:
>
> OVS 2.7:
>
>   ??.??% - dp_netdev_process_rxq_port
>   |-- 93.36% - dp_netdev_input
>   |-- ??.??% - netdev_rxq_recv
>
> OVS 2.9:
>
>   99.69% - dp_netdev_process_rxq_port
>   |-- 79.45% - dp_netdev_input
>   |-- 11.26% - dp_netdev_pmd_flush_output_packets
>   |-- ??.??% - netdev_rxq_recv
>
> Could you please fill the missed (??.??) values?
> This data I got from the picture attached to the previous mail, but
> pictures
> are still not allowed in mail-list (i.e. stripped). It'll be good if you
> can
> upload your raw data to some external resource and post the link here.
>
> Anyway, from the data I have, I can see that total sum of time spent in
> "dp_netdev_input" and "dp_netdev_pmd_flush_output_packets" for 2.9 is
> 90.71%,
> which is less then 93.36% spent for 2.7. This means that processing +
> sending
> become even faster or remains with the approximately same performance.
> We definitely need all the missed values to be sure, but it seems that the
> "netdev_rxq_recv()" could be the issue.
>
> To check if DPDK itself causes the performance regression, I'd ask you
> to check pure PHY-PHY test with testpmd app from DPDK 16.11 and DPDK 17.11.
> Maybe it's the performance issue with bnxt driver that you're using.
> There was too many changes in that driver:
>
>   30 files changed, 17189 insertions(+), 3358 deletions(-)
>
> Best regards, Ilya Maximets.
>
> On 20.06.2018 01:18, Shahaji Bhosle wrote:
> > Hi Ilya,
> > This issue is a release blocker for us, just wanted to check check if
> you need more details from us? Anything to expedite or root cause the
> problem we can help
> > Please let us know
> > Thanks Shahaji
> >
> > On Mon, Jun 18, 2018 at 10:20 AM Shahaji Bhosle <
> shahaji.bho...@broadcom.com > wrote:
> >
> > Thanks Ilya, I will look at the commit, but not sure now how to tell
> how much real work is being done, I would have liked polling cycles to be
> treated as before and not towards packet processing. That does explain, as
> long as there are packets on the wire we are always 100%, basically cannot
> tell how efficiently the CPUs are being used.
> > Thanks, Shahaji
> >
> > On Mon, Jun 18, 2018 at 10:07 AM, Ilya Maximets <
> i.maxim...@samsung.com > wrote:
> >
> > Thanks for the data.
> >
> > I have to note additionally that the meaning of "processing
> cycles"
> > significantly changed since the following commit:
> >
> > commit a2ac666d5265c01661e189caac321d962f54649f
> > Author: Ciara Loftus  ciara.lof...@intel.com>>
> > Date:   Mon Feb 20 12:53:00 2017 +
> >
> > dpif-netdev: Change definitions of 'idle' & 'processing'
> cycles
> >
> > Instead of counting all polling cycles as processing
> cycles, only count
> > the cycles where packets were received from the polling.
> >
> > This could explain the difference in "PMD Processing Cycles"
> column,
> > because successful "POLLING" cycles are now included into
> "PROCESSING".
> >
> > Best regards, Ilya Maximets.
> >
> > On 18.06.2018 16:31, Shahaji Bhosle wrote:
> > > Hi Ilya,
> > > Thanks for the quick reply,
> > > Please find the numbers for our PHY-PHY test, please note that
> with OVS 2.9.1 + DPDK 17.11 even a 10% of the below numbers will make the
> OVS 2.9+DPDK17.11 processing cycles to hit 100%, but 2.7 will on our setup
> never goes above 75% for processing cycles. I am also attaching the perf
> report between the two code bases and I think the
> "11.26%--dp_netdev_pmd_flush_output_packets" is causing us to take the
> performance hit. Out testing is also SRIOV and CPUs are ARM A72 cores. We
> are happy to run more tests, it is not easy for use to move back to OVS
> 2.8, but could happy to try more experiments if it helps us narrow down
> further. Please note we have also tried increasing the tx-flush-interval
> and it helps a little but still not significant enough. Let us know.
> > >
> > > Thanks, Shahaji
> > >
> > >
> > > *Setup:*
> > > IXIAPort 0 {(PF0)==[OVS+DPDK]==(PF1)} Port
> 1<-SFP28>IXIA
> > >
>

[ovs-dev] [PATCH] dpdk: Use DPDK 16.11.7 release.

2018-06-20 Thread Ian Stokes

Modify travis linux build script to use the latest
DPDK stable release 16.11.7. Update docs for latest
DPDK stable releases.

Signed-off-by: Ian Stokes 
---
 .travis/linux-build.sh   | 2 +-
 Documentation/faq/releases.rst   | 2 +-
 Documentation/intro/install/dpdk.rst | 6 +++---
 Documentation/topics/dpdk/vhost-user.rst | 6 +++---
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index 7909c0c..3af3454 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -80,7 +80,7 @@ fi
 
 if [ "$DPDK" ]; then
 if [ -z "$DPDK_VER" ]; then
-DPDK_VER="16.11.6"
+DPDK_VER="16.11.7"
 fi
 install_dpdk $DPDK_VER
 if [ "$CC" = "clang" ]; then
diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst
index 8636927..7922888 100644
--- a/Documentation/faq/releases.rst
+++ b/Documentation/faq/releases.rst
@@ -160,7 +160,7 @@ Q: What DPDK version does each Open vSwitch release work 
with?
 2.4.x2.0
 2.5.x2.2
 2.6.x16.07.2
-2.7.x16.11.6
+2.7.x16.11.7
  ===
 
 Q: Are all the DPDK releases that OVS versions work with maintained?
diff --git a/Documentation/intro/install/dpdk.rst 
b/Documentation/intro/install/dpdk.rst
index abc1355..d646f79 100644
--- a/Documentation/intro/install/dpdk.rst
+++ b/Documentation/intro/install/dpdk.rst
@@ -64,9 +64,9 @@ Install DPDK
 #. Download the `DPDK sources`_, extract the file and set ``DPDK_DIR``::
 
$ cd /usr/src/
-   $ wget http://fast.dpdk.org/rel/dpdk-16.11.6.tar.xz
-   $ tar xf dpdk-16.11.6.tar.xz
-   $ export DPDK_DIR=/usr/src/dpdk-stable-16.11.6
+   $ wget http://fast.dpdk.org/rel/dpdk-16.11.7.tar.xz
+   $ tar xf dpdk-16.11.7.tar.xz
+   $ export DPDK_DIR=/usr/src/dpdk-stable-16.11.7
$ cd $DPDK_DIR
 
 #. (Optional) Configure DPDK as a shared library
diff --git a/Documentation/topics/dpdk/vhost-user.rst 
b/Documentation/topics/dpdk/vhost-user.rst
index 215773b..504a46d 100644
--- a/Documentation/topics/dpdk/vhost-user.rst
+++ b/Documentation/topics/dpdk/vhost-user.rst
@@ -271,9 +271,9 @@ To begin, instantiate a guest as described in 
:ref:`dpdk-vhost-user` or
 DPDK sources to VM and build DPDK::
 
 $ cd /root/dpdk/
-$ wget http://fast.dpdk.org/rel/dpdk-16.11.6.tar.xz
-$ tar xf dpdk-16.11.6.tar.xz
-$ export DPDK_DIR=/root/dpdk/dpdk-stable-16.11.6
+$ wget http://fast.dpdk.org/rel/dpdk-16.11.7.tar.xz
+$ tar xf dpdk-16.11.7.tar.xz
+$ export DPDK_DIR=/root/dpdk/dpdk-stable-16.11.7
 $ export DPDK_TARGET=x86_64-native-linuxapp-gcc
 $ export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET
 $ cd $DPDK_DIR
-- 
2.7.5

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] dpdk: Use DPDK 17.11.3 release.

2018-06-20 Thread Ian Stokes

Modify travis linux build script to use the latest
DPDK stable release 17.11.3. Update docs for latest
DPDK stable releases.

Signed-off-by: Ian Stokes 
---
 .travis/linux-build.sh   | 2 +-
 Documentation/faq/releases.rst   | 4 ++--
 Documentation/intro/install/dpdk.rst | 8 
 Documentation/topics/dpdk/vhost-user.rst | 6 +++---
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index 2e611f8..4b9fc4a 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -83,7 +83,7 @@ fi
 
 if [ "$DPDK" ]; then
 if [ -z "$DPDK_VER" ]; then
-DPDK_VER="17.11.2"
+DPDK_VER="17.11.3"
 fi
 install_dpdk $DPDK_VER
 if [ "$CC" = "clang" ]; then
diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst
index fab93b1..7021cec 100644
--- a/Documentation/faq/releases.rst
+++ b/Documentation/faq/releases.rst
@@ -163,9 +163,9 @@ Q: What DPDK version does each Open vSwitch release work 
with?
 2.4.x2.0
 2.5.x2.2
 2.6.x16.07.2
-2.7.x16.11.6
+2.7.x16.11.7
 2.8.x17.05.2
-2.9.x17.11.2
+2.9.x17.11.3
  ===
 
 Q: Are all the DPDK releases that OVS versions work with maintained?
diff --git a/Documentation/intro/install/dpdk.rst 
b/Documentation/intro/install/dpdk.rst
index 085e479..9e885ec 100644
--- a/Documentation/intro/install/dpdk.rst
+++ b/Documentation/intro/install/dpdk.rst
@@ -40,7 +40,7 @@ Build requirements
 In addition to the requirements described in :doc:`general`, building Open
 vSwitch with DPDK will require the following:
 
-- DPDK 17.11.2
+- DPDK 17.11.3
 
 - A `DPDK supported NIC`_
 
@@ -69,9 +69,9 @@ Install DPDK
 #. Download the `DPDK sources`_, extract the file and set ``DPDK_DIR``::
 
$ cd /usr/src/
-   $ wget http://fast.dpdk.org/rel/dpdk-17.11.2.tar.xz
-   $ tar xf dpdk-17.11.2.tar.xz
-   $ export DPDK_DIR=/usr/src/dpdk-stable-17.11.2
+   $ wget http://fast.dpdk.org/rel/dpdk-17.11.3.tar.xz
+   $ tar xf dpdk-17.11.3.tar.xz
+   $ export DPDK_DIR=/usr/src/dpdk-stable-17.11.3
$ cd $DPDK_DIR
 
 #. (Optional) Configure DPDK as a shared library
diff --git a/Documentation/topics/dpdk/vhost-user.rst 
b/Documentation/topics/dpdk/vhost-user.rst
index c5b69fa..b1e2285 100644
--- a/Documentation/topics/dpdk/vhost-user.rst
+++ b/Documentation/topics/dpdk/vhost-user.rst
@@ -320,9 +320,9 @@ To begin, instantiate a guest as described in 
:ref:`dpdk-vhost-user` or
 DPDK sources to VM and build DPDK::
 
 $ cd /root/dpdk/
-$ wget http://fast.dpdk.org/rel/dpdk-17.11.2.tar.xz
-$ tar xf dpdk-17.11.2.tar.xz
-$ export DPDK_DIR=/root/dpdk/dpdk-stable-17.11.2
+$ wget http://fast.dpdk.org/rel/dpdk-17.11.3.tar.xz
+$ tar xf dpdk-17.11.3.tar.xz
+$ export DPDK_DIR=/root/dpdk/dpdk-stable-17.11.3
 $ export DPDK_TARGET=x86_64-native-linuxapp-gcc
 $ export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET
 $ cd $DPDK_DIR
-- 
2.7.5

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] eBPF and OVS

2018-06-20 Thread Ian Stokes


On 6/14/2018 11:31 PM, William Tu wrote:

On Thu, Jun 14, 2018 at 3:25 PM, Ben Pfaff  wrote:

On Mon, Jun 11, 2018 at 10:32:52AM +, Stokes, Ian wrote:

Hi all,

The recent DPDK 18.05 release provides BPF functionality for DPDK devices.

The BPF Library provides the ability to load and execute Enhanced Berkeley 
Packet Filters (eBPF) within user-space DPDK applications. It also introduces a 
basic framework to load/unload BPF-based filters on Eth devices (right now only 
via SW RX/TX callbacks). It also adds a dependency on libelf.

I'm just wondering if anyone is currently looking at BPF in OVS (either kernel 
or userspace). Specifically, if BPF will be supported in a future OVS release 
then is there a need to coordinate on the approach of how it is enabled?


Yes, we are actively working on eBPF datapath for the same features in
OVS kernel datapath.


Thanks for the response William,


Hopefully we can get to a stable state and send an RFC patch next month.



Great, would be interested to see this.


Does BPF functionality for DPDK support eBPF map and helper functions?


I dont think it supports map, from the DPDK docs it supports the 
following functionality


Create a new BPF execution context and load user provided eBPF code into it.
Destroy an BPF execution context and its runtime structures and free the 
associated memory.

Execute eBPF bytecode associated with provided input parameter.
Provide information about natively compiled code for given BPF context.
Load BPF program from the ELF file and install callback to execute it on 
given ethdev port/queue.


It's missing the following currently:

JIT for non X86_64 platforms.
cBPF.
tail-pointer call.
eBPF MAP.
skb.
external function calls for 32-bit platforms.

If these are required then it will need to be implemented in DPDK to 
allign for OVS I would think. Do you see anything in this list (besides 
mapping) that would be required?


Ian


Regards,
William



___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] ovn-northd: Apply pre ACLs when using Port Groups

2018-06-20 Thread Lucas Alvares Gomes

On Wed, Jun 20, 2018 at 3:18 AM, Daniel Alvarez  wrote:
> When using Port Groups, the pre ACLs were not applied so the
> conntrack action was not performed. This patch takes Port Groups
> into account when processing the pre ACLs.
>
> As a follow up, we could enhance this patch by creating an index
> from lswitch to port groups.
>
> Signed-off-by: Daniel Alvarez 
> ---
>  ovn/northd/ovn-northd.c | 100 
> +++-
>  tests/ovn.at|   2 +-
>  2 files changed, 57 insertions(+), 45 deletions(-)
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 72fe4e795..818ac59fa 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -2835,8 +2835,47 @@ build_dhcpv6_action(struct ovn_port *op, struct 
> in6_addr *offer_ip,
>  return true;
>  }
>
> +struct ovn_port_group_ls {
> +struct hmap_node key_node;  /* Index on 'key'. */
> +struct uuid key;/* nb_ls->header_.uuid. */
> +const struct nbrec_logical_switch *nb_ls;
> +};
> +
> +struct ovn_port_group {
> +struct hmap_node key_node;  /* Index on 'key'. */
> +struct uuid key;/* nb_pg->header_.uuid. */
> +const struct nbrec_port_group *nb_pg;
> +struct hmap nb_lswitches;   /* NB lswitches related to the port group */
> +size_t n_acls;  /* Number of ACLs applied to the port group 
> */
> +struct nbrec_acl **acls;/* ACLs applied to the port group */
> +};
> +
> +static void
> +ovn_port_group_ls_add(struct ovn_port_group *pg,
> +  const struct nbrec_logical_switch *nb_ls)
> +{
> +struct ovn_port_group_ls *pg_ls = xzalloc(sizeof *pg_ls);
> +pg_ls->key = nb_ls->header_.uuid;
> +pg_ls->nb_ls = nb_ls;
> +hmap_insert(&pg->nb_lswitches, &pg_ls->key_node, uuid_hash(&pg_ls->key));
> +}
> +
> +static struct ovn_port_group_ls *
> +ovn_port_group_ls_find(struct ovn_port_group *pg, const struct uuid *ls_uuid)
> +{
> +struct ovn_port_group_ls *pg_ls;
> +
> +HMAP_FOR_EACH_WITH_HASH (pg_ls, key_node, uuid_hash(ls_uuid),
> + &pg->nb_lswitches) {
> +if (uuid_equals(ls_uuid, &pg_ls->key)) {
> +return pg_ls;
> +}
> +}
> +return NULL;
> +}
> +
>  static bool
> -has_stateful_acl(struct ovn_datapath *od)
> +has_stateful_acl(struct ovn_datapath *od, struct hmap *port_groups)
>  {
>  for (size_t i = 0; i < od->nbs->n_acls; i++) {
>  struct nbrec_acl *acl = od->nbs->acls[i];
> @@ -2845,13 +2884,25 @@ has_stateful_acl(struct ovn_datapath *od)
>  }
>  }
>
> +struct ovn_port_group *pg;
> +HMAP_FOR_EACH (pg, key_node, port_groups) {
> +if (ovn_port_group_ls_find(pg, &od->nbs->header_.uuid)) {
> +for (size_t i = 0; i < pg->n_acls; i++) {
> +struct nbrec_acl *acl = pg->acls[i];
> +if (!strcmp(acl->action, "allow-related")) {
> +return true;
> +}
> +}
> +}
> +}
>  return false;
>  }
>
>  static void
> -build_pre_acls(struct ovn_datapath *od, struct hmap *lflows)
> +build_pre_acls(struct ovn_datapath *od, struct hmap *lflows,
> +   struct hmap *port_groups)
>  {
> -bool has_stateful = has_stateful_acl(od);
> +bool has_stateful = has_stateful_acl(od, port_groups);
>
>  /* Ingress and Egress Pre-ACL Table (Priority 0): Packets are
>   * allowed by default. */
> @@ -3309,21 +3360,6 @@ consider_acl(struct hmap *lflows, struct ovn_datapath 
> *od,
>  free(stage_hint);
>  }
>
> -struct ovn_port_group_ls {
> -struct hmap_node key_node;  /* Index on 'key'. */
> -struct uuid key;/* nb_ls->header_.uuid. */
> -const struct nbrec_logical_switch *nb_ls;
> -};
> -
> -struct ovn_port_group {
> -struct hmap_node key_node;  /* Index on 'key'. */
> -struct uuid key;/* nb_pg->header_.uuid. */
> -const struct nbrec_port_group *nb_pg;
> -struct hmap nb_lswitches;   /* NB lswitches related to the port group */
> -size_t n_acls;  /* Number of ACLs applied to the port group 
> */
> -struct nbrec_acl **acls;/* ACLs applied to the port group */
> -};
> -
>  static struct ovn_port_group *
>  ovn_port_group_create(struct hmap *pgs,
>const struct nbrec_port_group *nb_pg)
> @@ -3338,30 +3374,6 @@ ovn_port_group_create(struct hmap *pgs,
>  return pg;
>  }
>
> -static void
> -ovn_port_group_ls_add(struct ovn_port_group *pg,
> -  const struct nbrec_logical_switch *nb_ls)
> -{
> -struct ovn_port_group_ls *pg_ls = xzalloc(sizeof *pg_ls);
> -pg_ls->key = nb_ls->header_.uuid;
> -pg_ls->nb_ls = nb_ls;
> -hmap_insert(&pg->nb_lswitches, &pg_ls->key_node, uuid_hash(&pg_ls->key));
> -}
> -
> -static struct ovn_port_group_ls *
> -ovn_port_group_ls_find(struct ovn_port_group *pg, const struct uuid *ls_uuid)
> -{
> -struct ovn_port_group_ls *pg_ls;
> -
> -H

[ovs-dev] [PATCH] Utilities: Add the ovs_show_fdb command to gdb

2018-06-20 Thread Eelco Chaudron

This adds the ovs_show_fdb command:

  Usage: ovs_show_fdb { {dbg} {hash}}

   : Optional bridge name, if not supplied FDB summary
  information is displayed for all bridges.
  dbg   : Will show structure address information
  hash  : Will display the forwarding table using the hash
  table, rather than the rlu list.

Some examples:

  (gdb) ovs_show_fdb
  br0: (struct mac_learning *) 0x139c160
  table.n : 0
  secret  : 0x6c42c707
  idle_time   : 300
  max_entries : 2048
  ref_count   : 2
  need_revalidate : false
  ports_by_ptr.n  : 0
  ports_by_usage.n: 0
  br1: (struct mac_learning *) 0x139b0b0
  table.n : 0
  secret  : 0xcf8efaf8
  idle_time   : 300
  max_entries : 2048
  ref_count   : 2
  need_revalidate : false
  ports_by_ptr.n  : 0
  ports_by_usage.n: 0
  ovs_pvp_br0: (struct mac_learning *) 0x137b470
  table.n : 4
  secret  : 0x623e75ad
  idle_time   : 300
  max_entries : 2048
  ref_count   : 2
  need_revalidate : false
  ports_by_ptr.n  : 4
  ports_by_usage.n: 4

  (gdb) ovs_show_fdb  ovs_pvp_br0
  table.n : 4
  secret  : 0x623e75ad
  idle_time   : 300
  max_entries : 2048
  ref_count   : 2
  need_revalidate : false
  ports_by_ptr.n  : 4
  ports_by_usage.n: 4

  FDB "lrus" table:
  port   VLAN  MACAge out @
  -    -  -
  02[vnet2] 0  52:54:00:b6:de:1e  81501
  01[vnet0] 0  52:54:00:0b:60:6e  81501
  03[vnet4] 0  52:54:00:89:32:4c  81501
  0LOCAL[ovs_pvp_br 0  5e:26:7b:41:28:46  81501

  Total MAC entries: 4

  Current time is between 81198 and 81203 seconds.

Signed-off-by: Eelco Chaudron 
---
 utilities/gdb/ovs_gdb.py | 191 ++-
 1 file changed, 188 insertions(+), 3 deletions(-)

diff --git a/utilities/gdb/ovs_gdb.py b/utilities/gdb/ovs_gdb.py
index 538383c72..65f9216d9 100644
--- a/utilities/gdb/ovs_gdb.py
+++ b/utilities/gdb/ovs_gdb.py
@@ -20,7 +20,7 @@
 #
 #  Notes:
 #It implements the following GDB commands:
-#- ovs_dump_bridge [ports|wanted]
+#- ovs_dump_bridge {ports|wanted}
 #- ovs_dump_bridge_ports 
 #- ovs_dump_dp_netdev [ports]
 #- ovs_dump_dp_netdev_poll_threads 
@@ -30,6 +30,7 @@
 #- ovs_dump_netdev_provider
 #- ovs_dump_ovs_list  {[] [] {dump}]}
 #- ovs_dump_simap 
+#- ovs_show_fdb {[] {dbg} {hash}}
 #
 #  Example:
 #$ gdb $(which ovs-vswitchd) $(pidof ovs-vswitchd)
@@ -117,6 +118,28 @@ def get_global_variable(name):
 return gdb.parse_and_eval(name)
 
 
+def get_time_msec():
+# There is no variable that stores the current time each iteration,
+# to get a decent time time_now() value. For now we take the global
+# "coverage_run_time" value, which is the current time + max 5 seconds
+# (COVERAGE_RUN_INTERVAL)
+return long(get_global_variable("coverage_run_time")), -5000
+
+
+def get_time_now():
+# See get_time_msec() above
+return long(get_global_variable("coverage_run_time"))/1000, -5
+
+
+def eth_addr_to_string(eth_addr):
+return "{:02x}:{:02x}:{:02x}:{:02x}:{:02x}:{:02x}".format(
+long(eth_addr['ea'][0]),
+long(eth_addr['ea'][1]),
+long(eth_addr['ea'][2]),
+long(eth_addr['ea'][3]),
+long(eth_addr['ea'][4]),
+long(eth_addr['ea'][5]))
+
 #
 # Class that will provide an iterator over an OVS cmap.
 #
@@ -286,7 +309,7 @@ class ForEachLIST():
 #
 class CmdDumpBridge(gdb.Command):
 """Dump all configured bridges.
-Usage: ovs_dump_bridge [ports|wanted]
+Usage: ovs_dump_bridge {ports|wanted}
 """
 def __init__(self):
 super(CmdDumpBridge, self).__init__("ovs_dump_bridge",
@@ -299,7 +322,7 @@ class CmdDumpBridge(gdb.Command):
 if len(arg_list) > 1 or \
(len(arg_list) == 1 and arg_list[0] != "ports" and
arg_list[0] != "wanted"):
-print("usage: ovs_dump_bridge [ports|wanted]")
+print("usage: ovs_dump_bridge {ports|wanted}")
 return
 elif len(arg_list) == 1:
 if arg_list[0] == "ports":
@@ -700,6 +723,167 @@ class CmdDumpSimap(gdb.Command):
values[name], values[name]))
 
 
+#
+# Implements the GDB "ovs_show_fdb" command
+#
+class CmdShowFDB(gdb.Command):
+"""Show FDB information
+Usage: ovs_show_fdb { {dbg} {hash}}
+
+: Optional bridge name, if not supplied FDB summary
+   information is displayed for all bridges.
+   dbg   : Will show structure address information
+   hash  : Will display the forwarding table using the hash
+   table, rather than the rlu list.
+"""
+
+def __init__(self):
+sup

Re: [ovs-dev] 64Byte packet performance regression on 2.9 from 2.7

2018-06-20 Thread Ilya Maximets

Looking at your perf stats I see following:

OVS 2.7:

  ??.??% - dp_netdev_process_rxq_port
  |-- 93.36% - dp_netdev_input
  |-- ??.??% - netdev_rxq_recv

OVS 2.9:

  99.69% - dp_netdev_process_rxq_port
  |-- 79.45% - dp_netdev_input
  |-- 11.26% - dp_netdev_pmd_flush_output_packets
  |-- ??.??% - netdev_rxq_recv

Could you please fill the missed (??.??) values?
This data I got from the picture attached to the previous mail, but pictures
are still not allowed in mail-list (i.e. stripped). It'll be good if you can
upload your raw data to some external resource and post the link here.

Anyway, from the data I have, I can see that total sum of time spent in
"dp_netdev_input" and "dp_netdev_pmd_flush_output_packets" for 2.9 is 90.71%,
which is less then 93.36% spent for 2.7. This means that processing + sending
become even faster or remains with the approximately same performance.
We definitely need all the missed values to be sure, but it seems that the
"netdev_rxq_recv()" could be the issue.

To check if DPDK itself causes the performance regression, I'd ask you
to check pure PHY-PHY test with testpmd app from DPDK 16.11 and DPDK 17.11.
Maybe it's the performance issue with bnxt driver that you're using.
There was too many changes in that driver:

  30 files changed, 17189 insertions(+), 3358 deletions(-)

Best regards, Ilya Maximets.

On 20.06.2018 01:18, Shahaji Bhosle wrote:
> Hi Ilya,
> This issue is a release blocker for us, just wanted to check check if you 
> need more details from us? Anything to expedite or root cause the problem we 
> can help 
> Please let us know 
> Thanks Shahaji 
> 
> On Mon, Jun 18, 2018 at 10:20 AM Shahaji Bhosle  > wrote:
> 
> Thanks Ilya, I will look at the commit, but not sure now how to tell how 
> much real work is being done, I would have liked polling cycles to be treated 
> as before and not towards packet processing. That does explain, as long as 
> there are packets on the wire we are always 100%, basically cannot tell how 
> efficiently the CPUs are being used.
> Thanks, Shahaji
> 
> On Mon, Jun 18, 2018 at 10:07 AM, Ilya Maximets  > wrote:
> 
> Thanks for the data.
> 
> I have to note additionally that the meaning of "processing cycles"
> significantly changed since the following commit:
> 
>     commit a2ac666d5265c01661e189caac321d962f54649f
>     Author: Ciara Loftus  >
>     Date:   Mon Feb 20 12:53:00 2017 +
> 
>         dpif-netdev: Change definitions of 'idle' & 'processing' 
> cycles
> 
>         Instead of counting all polling cycles as processing cycles, 
> only count
>         the cycles where packets were received from the polling.
> 
> This could explain the difference in "PMD Processing Cycles" column,
> because successful "POLLING" cycles are now included into 
> "PROCESSING".
> 
> Best regards, Ilya Maximets.
> 
> On 18.06.2018 16:31, Shahaji Bhosle wrote:
> > Hi Ilya,
> > Thanks for the quick reply, 
> > Please find the numbers for our PHY-PHY test, please note that with 
> OVS 2.9.1 + DPDK 17.11 even a 10% of the below numbers will make the OVS 
> 2.9+DPDK17.11 processing cycles to hit 100%, but 2.7 will on our setup never 
> goes above 75% for processing cycles. I am also attaching the perf report 
> between the two code bases and I think the  
> "11.26%--dp_netdev_pmd_flush_output_packets" is causing us to take the 
> performance hit. Out testing is also SRIOV and CPUs are ARM A72 cores. We are 
> happy to run more tests, it is not easy for use to move back to OVS 2.8, but 
> could happy to try more experiments if it helps us narrow down further. 
> Please note we have also tried increasing the tx-flush-interval and it helps 
> a little but still not significant enough. Let us know.
> > 
> > Thanks, Shahaji 
> > 
> > 
> > *Setup:*
> > IXIAPort 0 {(PF0)==[OVS+DPDK]==(PF1)} Port 
> 1<-SFP28>IXIA
> > 
> > release/version       config  Test    direction       MPPS    Ixia 
> Line rate (%)      PMD Processing Cycles (%)
> > OVS 2.9 + DPDK 17.11  OVS on Maia (PF0--PF1)  No drop port 1 to 2   
>   31.3    85      99.9
> >                                                       port 2 to 1   
>   31.3    85      99.9
> >                                                       bi      15.5 
> + 15.5     42      99.9
> >                                               
> >                                               
> > OVS 2.7 + DPDK 16.11  OVS on Maia (PF0--PF1)  No drop port 1 to 2   
>   33.8    90      71
> >                                                       port 2 to 1   
>   32.7    88      70
> >                                                       bi      
>

[ovs-dev] [PATCH] rconn: Suppress 'connected' log for unreliable connections.

2018-06-20 Thread Ilya Maximets

Recent assertion failure fix changed rconn workflow for unreliable
connections (such as connections from ovs-ofctl) from

|rconn|DBG|br-int<->unix#151: entering ACTIVE
|rconn|DBG|br-int<->unix#151: connection closed by peer
|rconn|DBG|br-int<->unix#151: entering DISCONNECTED

To

|rconn|DBG|br-int<->unix#200: entering CONNECTING
|rconn|INFO|br-int<->unix#200: connected
|rconn|DBG|br-int<->unix#200: entering ACTIVE
|rconn|DBG|br-int<->unix#200: connection closed by peer
|rconn|DBG|br-int<->unix#200: entering DISCONNECTED

Many monitoring/configuring tools (ex. ovs-neutron-agent) uses
ovs-ofctl frequently to check the statuses of installed flows.
This produces a lot of "connected" logs, that are useless in general.

Fix that by changing the log level to DBG for unreliable connections.

Suggested-by: Ben Pfaff 
Fixes: c9a9b9b00bf5 ("rconn: Introduce new invariant to fix assertion
  failure in corner case.")
Signed-off-by: Ilya Maximets 
---
 lib/rconn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/rconn.c b/lib/rconn.c
index 7af4e73..ece8769 100644
--- a/lib/rconn.c
+++ b/lib/rconn.c
@@ -511,7 +511,7 @@ run_CONNECTING(struct rconn *rc)
 {
 int retval = vconn_connect(rc->vconn);
 if (!retval) {
-VLOG_INFO("%s: connected", rc->name);
+VLOG(rc->reliable ? VLL_INFO : VLL_DBG, "%s: connected", rc->name);
 rc->n_successful_connections++;
 state_transition(rc, S_ACTIVE);
 rc->version = vconn_get_version(rc->vconn);
-- 
2.7.4

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] rconn: Introduce new invariant to fix assertion failure in corner case.

2018-06-20 Thread Ilya Maximets

On 19.06.2018 19:03, Ben Pfaff wrote:
> On Tue, Jun 19, 2018 at 10:58:36AM +0300, Ilya Maximets wrote:
>> On 18.06.2018 22:24, Ben Pfaff wrote:
>>> On Mon, Jun 18, 2018 at 06:34:13PM +0300, Ilya Maximets wrote:
 On 18.06.2018 18:07, Ben Pfaff wrote:
> On Mon, Jun 18, 2018 at 05:18:49PM +0300, Ilya Maximets wrote:
>>> On Wed, May 23, 2018 at 09:28:59PM -0700, Ben Pfaff wrote:
 On Wed, May 23, 2018 at 06:06:44PM -0700, Han Zhou wrote:
> On Wed, May 23, 2018 at 5:14 PM, Ben Pfaff  wrote:
>>
>> Until now, rconn_get_version() has only reported the OpenFlow 
>> version in
>> use when the rconn is actually connected.  This makes sense, but it 
>> has a
>> harsh consequence.  Consider code like this:
>>
>> if (rconn_is_connected(rconn) && rconn_get_version(rconn) >= 0) {
>> for (int i = 0; i < 2; i++) {
>> struct ofpbuf *b = ofputil_encode_echo_request(
>> rconn_get_version(rconn));
>> rconn_send(rconn, b, NULL);
>> }
>> }
>>
>> Maybe not the smartest code in the world, and probably no one would 
>> write
>> this exact code in any case, but it doesn't look too risky or crazy.
>>
>> But it is.  The second trip through the loop can assert-fail inside
>> ofputil_encode_echo_request() because rconn_get_version(rconn) 
>> returns -1
>> instead of a valid OpenFlow version.  That happens if the first call 
>> to
>> rconn_send() encounters an error while sending the message and 
>> therefore
>> destroys the underlying vconn and disconnects so that 
>> rconn_get_version()
>> doesn't have a vconn to query for its version.
>>
>> In a case like this where all the code to send the messages is close 
>> by,
> we
>> could just check rconn_get_version() in each loop iteration.  We 
>> could
> even
>> go through the tree and convince ourselves that individual bits of 
>> code
> are
>> safe, or be conservative and check rconn_get_version() >= 0 in the 
>> iffy
>> cases.  But this seems to me like an ongoing source of risk and a 
>> way to
>> get things wrong in corner cases.
>>
>> This commit takes a different approach.  It introduces a new 
>> invariant: if
>> an rconn has ever been connected, then it returns a valid OpenFlow 
>> version
>> from rconn_get_version().  In addition, if an rconn is currently
> connected,
>> then the OpenFlow version it returns is the correct one (that may be
>> obvious, but there were corner cases before where it returned -1 even
>> though rconn_is_connected() returned true).
>>
>> With this commit, the code above would work OK.  If the first call to
>> rconn_send() encounters an error sending the message, then
>> rconn_get_version() in the second iteration will return the same 
>> value as
>> in the first iteration.  The message passed to rconn_send() will end 
>> up
>> being discarded, but that's much better than either an assertion 
>> failure
> or
>> having to carefully analyze a lot of our code to deal with one 
>> unusual
>> corner case.
>>
>> Reported-by: Han Zhou 
>> Signed-off-by: Ben Pfaff 
>> ---
>>  lib/learning-switch.c |  2 +-
>>  lib/rconn.c   | 41 -
>>  lib/vconn.c   |  1 +
>>  3 files changed, 18 insertions(+), 26 deletions(-)
>>
> Acked-by: Han Zhou 

 Thanks.  I applied this to master.  I'll backport it to older versions
 if no one notices trouble soon.
>>>
>>> I backported as far as branch-2.5.
>>
>> Sorry for being late, but I just tried to use branch-2.9 on my test 
>> environment
>> and found that this patch produces a lot of "connected" logs that are a 
>> bit annoying:
>>
>> 2018-06-18T12:55:06.610Z|03051|rconn|INFO|br-int<->unix#2873: connected
>> 2018-06-18T12:55:08.609Z|03052|rconn|INFO|br-int<->unix#2874: connected
>> 2018-06-18T12:55:08.610Z|03053|rconn|INFO|br-int<->unix#2875: connected
>> 2018-06-18T12:55:10.608Z|03054|rconn|INFO|br-int<->unix#2876: connected
>> 2018-06-18T12:55:10.609Z|03055|rconn|INFO|br-int<->unix#2877: connected
>> 2018-06-18T12:55:12.609Z|03056|rconn|INFO|br-int<->unix#2878: connected
>> 2018-06-18T12:55:12.609Z|03057|rconn|INFO|br-int<->unix#2879: connected
>> 2018-06-18T12:55:14.612Z|03058|rconn|INFO|br-int<->unix#2880: connected
>> 2018-06-18T12:55:14.613Z|03059|rconn|INFO|br-int<->unix#2881: connected
>>>

43 matches

Mail list logo