Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum flags on init.

2017-08-09 Thread Darrell Ball


-Original Message-
From: Ben Pfaff 
Date: Wednesday, August 9, 2017 at 10:40 AM
To: Darrell Ball 
Cc: Darrell Ball , "d...@openvswitch.org" 

Subject: Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum flags on 
init.

On Wed, Aug 09, 2017 at 05:32:02PM +, Darrell Ball wrote:
> 
> 
> -Original Message-
> From:  on behalf of Ben Pfaff 

> Date: Wednesday, August 9, 2017 at 10:15 AM
> To: Darrell Ball 
> Cc: "d...@openvswitch.org" 
> Subject: Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum 
flags on init.
> 
> On Tue, Aug 08, 2017 at 06:54:46PM -0700, Darrell Ball wrote:
> > Reset the DPDK HWOL checksum flags in dp_packet_init_.
> > The new HWOL bad checksum flag is uninitialized for non-dpdk ports 
and
> > this is noticed as test failures using netdev-dummy ports, when 
built with
> > the --with-dpdk flag set. Hence, in this case, packets may be 
marked as
> > having a bad checksum.
>
> > diff --git a/lib/dp-packet.c b/lib/dp-packet.c
> > index 67aa406..4926993 100644
> > --- a/lib/dp-packet.c
> > +++ b/lib/dp-packet.c
> > @@ -31,6 +31,7 @@ dp_packet_init__(struct dp_packet *b, size_t 
allocated, enum dp_packet_source so
> >  dp_packet_reset_offsets(b);
> >  pkt_metadata_init(>md, 0);
> >  dp_packet_rss_invalidate(b);
> > +reset_dp_packet_checksum_ol_flags(b);
> 
> This function un-sets some bits in p->mbuf.ol_flags.  The need for 
this
> implies that nothing initializes p->mbuf.ol_flags. 
> 
> Correct, I reused reset_dp_packet_checksum_ol_flags() to do the 
initialization as well
> I could also have created a separate function.
> 
> In case a DPDK dev is used, those flags will be managed by DPDK.
>
>  That sounds like a
> bug in itself--is there a missing call to initialize the mbuf 
somewhere?
> 
> Are you suggesting to initialize the whole mbuf for each packet ?

The issue that I'm raising is that it's unusual to take an
uninitialized, indeterminate field, and then initialize it by clearing a
few bits.  It's much more conventional to initialize it by setting it to
zero, like this:

p->mbuf.ol_flags = 0;


That is better; I will create a separate function then.
I will resend
Thanks


That made me wonder whether there's a larger problem of a failure to
initialize the mbuf more generally, although of course that does not
necessarily follow.


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


Re: [ovs-dev] [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to support variable length

2017-08-09 Thread Ben Pfaff
On Wed, Aug 09, 2017 at 07:45:13PM +0800, Yi Yang wrote:
> In order to adapt to MD type 1 and MD type 2 at the same
> time and avoid breaking Linux kernel uAPI later, we change
> struct ovs_action_encap_nsh to the below format.
> 
> struct ovs_action_encap_nsh {
> uint8_t flags;
> uint8_t mdtype;
> uint8_t mdlen;
> uint8_t np;
> __be32 path_hdr;
> uint8_t metadata[];
> };
> 
> struct ovs_action_encap_nsh will be allocated dynamically when
> it is used.
> 
> The following patch will change encap_nsh and decap_nsh into
> push_nsh and pop_nsh, respectively, Linux kernel guys prefer
> push_* and pop_*.
> 
> Signed-off-by: Yi Yang 

This is an unusual format for a Netlink attribute.  More commonly, one
would put variable-length data into an attribute of its own, which
allows that data to be handled using the regular Netlink means.  Then
the mdlen and metadata members could be removed, since they would be
part of the additional attribute, and one might expect the mdtype member
to be removed as well since each type of metadata would be in a
different attribute type.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] dp-packet: Use OVS_UNUSED to mark possibly unused parameters.

2017-08-09 Thread Ben Pfaff
Thanks, applied to master.

On Wed, Aug 09, 2017 at 06:09:12PM +, Darrell Ball wrote:
> Acked-by: Darrell Ball 
> 
> -Original Message-
> From:  on behalf of Ben Pfaff 
> Date: Wednesday, August 9, 2017 at 10:43 AM
> To: "d...@openvswitch.org" 
> Cc: Ben Pfaff 
> Subject: [ovs-dev] [PATCH] dp-packet: Use OVS_UNUSED to mark possibly unused  
> parameters.
> 
> This is the way usually used in OVS.
> 
> Signed-off-by: Ben Pfaff 
> ---
>  lib/dp-packet.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/lib/dp-packet.h b/lib/dp-packet.h
> index 9dbb611d95fb..8f52feeefa39 100644
> --- a/lib/dp-packet.h
> +++ b/lib/dp-packet.h
> @@ -615,46 +615,46 @@ dp_packet_rss_invalidate(struct dp_packet *p)
>  }
>  
>  static inline bool
> -dp_packet_ip_checksum_valid(struct dp_packet *p)
> +dp_packet_ip_checksum_valid(struct dp_packet *p OVS_UNUSED)
>  {
>  #ifdef DPDK_NETDEV
>  return (p->mbuf.ol_flags & PKT_RX_IP_CKSUM_MASK) ==
>  PKT_RX_IP_CKSUM_GOOD;
>  #else
> -return 0 && p;
> +return false;
>  #endif
>  }
>  
>  static inline bool
> -dp_packet_ip_checksum_bad(struct dp_packet *p)
> +dp_packet_ip_checksum_bad(struct dp_packet *p OVS_UNUSED)
>  {
>  #ifdef DPDK_NETDEV
>  return (p->mbuf.ol_flags & PKT_RX_IP_CKSUM_MASK) ==
>  PKT_RX_IP_CKSUM_BAD;
>  #else
> -return 0 && p;
> +return false;
>  #endif
>  }
>  
>  static inline bool
> -dp_packet_l4_checksum_valid(struct dp_packet *p)
> +dp_packet_l4_checksum_valid(struct dp_packet *p OVS_UNUSED)
>  {
>  #ifdef DPDK_NETDEV
>  return (p->mbuf.ol_flags & PKT_RX_L4_CKSUM_MASK) ==
>  PKT_RX_L4_CKSUM_GOOD;
>  #else
> -return 0 && p;
> +return false;
>  #endif
>  }
>  
>  static inline bool
> -dp_packet_l4_checksum_bad(struct dp_packet *p)
> +dp_packet_l4_checksum_bad(struct dp_packet *p OVS_UNUSED)
>  {
>  #ifdef DPDK_NETDEV
>  return (p->mbuf.ol_flags & PKT_RX_L4_CKSUM_MASK) ==
>  PKT_RX_L4_CKSUM_BAD;
>  #else
> -return 0 && p;
> +return false;
>  #endif
>  }
>  
> -- 
> 2.10.2
> 
> ___
> dev mailing list
> d...@openvswitch.org
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=0RZDgi3QSeTa-OACTsQTtSjiq06eE5_d3BVy9x27k0I=JFbjrYsebeV29PPEYqsW3vTei-H5PjvFb2Z1MaYTZYY=
>  
> 
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] ofproto-dpif: Mark packets as "untracked" after call to ct().

2017-08-09 Thread Justin Pettit
Hmm, it was the first time I'd used the internal system tester so I must have 
invoked it improperly.  I'll fix these issues and send out a v2.

Thanks,

--Justin


> On Aug 8, 2017, at 6:02 PM, Darrell Ball  wrote:
> 
> I just did a second round
> 
> One correction for first round 73 should have been 79
> 
> First round:
> Kernel: 53, 58, 69, 70
> Userspace: 57, 58, 63, 69, 70, 71, 72, 79
> 
> Second Round:
> Kernel: 53, 58, 69, 70
> Userspace: 58, 63, 69, 70, 71, 72, 79
> 
> Without patch, no failures on both.
> 
> 
> 
> -Original Message-
> From: Darrell Ball 
> Date: Tuesday, August 8, 2017 at 5:51 PM
> To: Justin Pettit 
> Cc: Justin Pettit , "d...@openvswitch.org" 
> 
> Subject: Re: [ovs-dev] [PATCH] ofproto-dpif: Mark packets as "untracked" 
> after call to ct().
> 
>I just rebased about 15 minutes ago:
> 
>Kernel: 53, 58, 69, 70
>Userspace: 57, 58, 63, 69, 70, 71, 72, 73
> 
>-Original Message-
>From: Justin Pettit 
>Date: Tuesday, August 8, 2017 at 5:48 PM
>To: Darrell Ball 
>Cc: Justin Pettit , "d...@openvswitch.org" 
> 
>Subject: Re: [ovs-dev] [PATCH] ofproto-dpif: Mark packets as "untracked" 
> after call to ct().
> 
>Can you share them? I don't see them on my system or our internal 
> system tester that runs the kernel and user space tests.  
> 
>--Justin
> 
> 
>> On Aug 8, 2017, at 5:46 PM, Darrell Ball  wrote:
>> 
>> With this patch applied:
>> 
>> I get 4 failures in kernel system tests and 8 failures in userspace system 
>> tests.
>> 
>> 
>> 
>> 
>> -Original Message-
>> From:  on behalf of Justin Pettit 
>> 
>> Date: Tuesday, August 8, 2017 at 4:12 PM
>> To: "d...@openvswitch.org" 
>> Subject: [ovs-dev] [PATCH] ofproto-dpif: Mark packets as "untracked" after   
>>  call to ct().
>> 
>>   Packet and Connection state is only available to the processing path
>>   that follows the "recirc_table" argument of the ct() action.  The
>>   previous behavior made these states available until the end of the
>>   pipeline.  This commit changes the behavior so that the Packet and
>>   Connection state are cleared for the current processing path whenever
>>   ct() is called (in addition to reaching the end of the pipeline.)
>> 
>>   A future commit will remove the behavior that a "send to controller"
>>   action causes all packets for that flow to be handled via the slow-path.
>>   The current behavior of connection tracking state makes that difficult
>>   due to datapath actions containing multiple OpenFlow rules that may
>>   contain different connection tracking states.  This change will make
>>   that future commit possible.
>> 
>>   Signed-off-by: Justin Pettit 
>>   ---
>>lib/ofp-actions.c| 27 +--
>>ofproto/ofproto-dpif-xlate.c | 24 +++-
>>tests/ofproto-dpif.at| 10 +-
>>utilities/ovs-ofctl.8.in | 10 ++
>>4 files changed, 31 insertions(+), 40 deletions(-)
>> 
>>   diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
>>   index bfc8a805ffd5..71eb70c3c239 100644
>>   --- a/lib/ofp-actions.c
>>   +++ b/lib/ofp-actions.c
>>   @@ -5858,20 +5858,19 @@ format_DEBUG_RECIRC(const struct ofpact_null *a 
>> OVS_UNUSED,
>> *
>> *   - Packet State:
>> *
>>   - *  Untracked packets have not yet passed through the connection 
>> tracker,
>>   - *  and the connection state for such packets is unknown. In most 
>> cases,
>>   - *  packets entering the OpenFlow pipeline will initially be in the
>>   - *  untracked state. Untracked packets may become tracked by executing
>>   - *  NXAST_CT with a "recirc_table" specified. This makes various 
>> aspects
>>   - *  about the connection available, in particular the connection 
>> state.
>>   - *
>>   - *  Tracked packets have previously passed through the connection 
>> tracker.
>>   - *  These packets will remain tracked through until the end of the 
>> OpenFlow
>>   - *  pipeline. Tracked packets which have NXAST_CT executed with a
>>   - *  "recirc_table" specified will return to the tracked state.
>>   - *
>>   - *  The packet state is only significant for the duration of packet
>>   - *  processing within the OpenFlow pipeline.
>>   + *  Untracked packets have an unknown connection state.  In most
>>   + *  cases, packets entering the OpenFlow pipeline will initially be
>>   + *  in the untracked state. Untracked packets may become tracked by
>>   + *  executing NXAST_CT with a "recirc_table" specified. This makes
>>   + *  various aspects about the connection available, in particular
>>   + *  the connection state.
>>   + *
>>   

Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum flags on init.

2017-08-09 Thread Chandran, Sugesh
Hi Darrel,

I reviewed and tested the patch.
It does fixed the UT failures in --with-dpdk case.

One comment below.

Regards
_Sugesh


> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of Darrell Ball
> Sent: Wednesday, August 9, 2017 6:58 PM
> To: Ben Pfaff 
> Cc: d...@openvswitch.org
> Subject: Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum
> flags on init.
> 
> 
> 
> -Original Message-
> From: Ben Pfaff 
> Date: Wednesday, August 9, 2017 at 10:40 AM
> To: Darrell Ball 
> Cc: Darrell Ball , "d...@openvswitch.org"
> 
> Subject: Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum
> flags on init.
> 
> On Wed, Aug 09, 2017 at 05:32:02PM +, Darrell Ball wrote:
> >
> >
> > -Original Message-
> > From:  on behalf of Ben Pfaff
> 
> > Date: Wednesday, August 9, 2017 at 10:15 AM
> > To: Darrell Ball 
> > Cc: "d...@openvswitch.org" 
> > Subject: Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL
> checksum flags on init.
> >
> > On Tue, Aug 08, 2017 at 06:54:46PM -0700, Darrell Ball wrote:
> > > Reset the DPDK HWOL checksum flags in dp_packet_init_.
> > > The new HWOL bad checksum flag is uninitialized for non-dpdk ports
> and
> > > this is noticed as test failures using netdev-dummy ports, when 
> built
> with
> > > the --with-dpdk flag set. Hence, in this case, packets may be 
> marked
> as
> > > having a bad checksum.
> >
> > > diff --git a/lib/dp-packet.c b/lib/dp-packet.c
> > > index 67aa406..4926993 100644
> > > --- a/lib/dp-packet.c
> > > +++ b/lib/dp-packet.c
> > > @@ -31,6 +31,7 @@ dp_packet_init__(struct dp_packet *b, size_t
> allocated, enum dp_packet_source so
> > >  dp_packet_reset_offsets(b);
> > >  pkt_metadata_init(>md, 0);
> > >  dp_packet_rss_invalidate(b);
> > > +reset_dp_packet_checksum_ol_flags(b);
> >
> > This function un-sets some bits in p->mbuf.ol_flags.  The need for 
> this
> > implies that nothing initializes p->mbuf.ol_flags.
> >
> > Correct, I reused reset_dp_packet_checksum_ol_flags() to do the
> initialization as well
> > I could also have created a separate function.
> >
> > In case a DPDK dev is used, those flags will be managed by DPDK.
> >
> >  That sounds like a
> > bug in itself--is there a missing call to initialize the mbuf 
> somewhere?
> >
> > Are you suggesting to initialize the whole mbuf for each packet ?
> 
> The issue that I'm raising is that it's unusual to take an
> uninitialized, indeterminate field, and then initialize it by clearing a
> few bits.  It's much more conventional to initialize it by setting it to
> zero, like this:
> 
> p->mbuf.ol_flags = 0;
> 
> 
> That is better; I will create a separate function then.
> I will resend
> Thanks
[Sugesh] I also agree with Ben here.
Currently OVS uses only checksum offload flags from mbuf(As I am aware of). 
But there are other flag bits that may get used in future like TSO.
So its better to initialize the mbuf properly before using.

Here is the mbuf reset function in DPDK that get called when an existing memory 
is mapped to 
Mbuf.  
I believe only the ol_flags are relevant for now in OVS.


static inline void rte_pktmbuf_reset(struct rte_mbuf *m)
{
m->next = NULL;
m->pkt_len = 0;
m->tx_offload = 0;
m->vlan_tci = 0;
m->vlan_tci_outer = 0;
m->nb_segs = 1;
m->port = 0xff;

m->ol_flags = 0;
m->packet_type = 0;
rte_pktmbuf_reset_headroom(m);

m->data_len = 0;
__rte_mbuf_sanity_check(m, 1);
}

> 
> 
> That made me wonder whether there's a larger problem of a failure to
> initialize the mbuf more generally, although of course that does not
> necessarily follow.
> 
> 
> ___
> 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 v4 0/6] OVS-DPDK rxq to pmd assignment improvements.

2017-08-09 Thread Kevin Traynor
For the DPDK datapath, by default rxqs are assigned to available pmds
in round robin order with no weight or priority.

It can happen that some very busy queues are handled by one pmd which
does not have enough cycles to prevent packets being dropped on them.
While at the same time another pmd which handles queues with no traffic
on them is essentially idle.

Rxq to pmd assignment happens as a result of a number of events and
when it does, the same unweighted round robin approach is applied
each time.

This patchset proposes to improve the round robin nature of rxq to pmd
assignment by counting the processing cycles used by the rxqs during
their operation and incorporating that data into assignment.

Before assigning in a round robin manner, the rxqs will be sorted in
order of the processing cycles they have been consuming. Assuming
multiple pmds, this ensures that the rxqs measured to be using the
most processing cycles will be assigned to different cores.

In some cases the measured cycles for an rxq may be not available as
the rxq is new or may not be useful for assignment as traffic patterns
may change.  In those cases the code will essentially fallback to being
round round similar to what currently exists. However, in the case
where data is available and a reliable indication of future rxq cycles
consumption, rxq to pmd distribution will be much improved.

V3 -> V4

4/6
Rebased to accomodate new cross numa assigment.

V2 -> V3

Dropped v2 1/7 as not reusing dpcls optimisation interval anymore

2/6
Moved unused functions to 3/6 to avoid compiler warning

3/6
Made pmd rxq interval independent from dpcls opt interval

4/6
Moved docs about rebalance command to when it is available in 6/6
Added logging info for pmd to rxq assignment

5/6
Added an example to docs

6/6
Noted in commit msg that Jan requested this for testing purposes

V1 -> V2

Dropped Ciara's patch to change how pmd cycles are counted as it merged.

6/7: Rebased unit tests.


Kevin Traynor (6):
  dpif-netdev: Change polled_queue to use dp_netdev_rxq.
  dpif-netdev: Add rxq processing cycle counters.
  dpif-netdev: Count the rxq processing cycles for an rxq.
  dpif-netdev: Change rxq_scheduling to use rxq processing cycles.
  dpif-netdev: Change pmd selection order.
  dpif-netdev: Add ovs-appctl dpif-netdev/pmd-rxq-rebalance.

 Documentation/howto/dpdk.rst |  26 +
 lib/dpif-netdev.c| 252 +++
 tests/pmd.at |   2 +-
 vswitchd/ovs-vswitchd.8.in   |   2 +
 4 files changed, 237 insertions(+), 45 deletions(-)

-- 
1.8.3.1

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


Re: [ovs-dev] [PATCH v3 4/6] dpif-netdev: Change rxq_scheduling to use rxq processing cycles.

2017-08-09 Thread Kevin Traynor
On 08/08/2017 07:15 PM, Greg Rose wrote:
> On 08/01/2017 08:58 AM, Kevin Traynor wrote:
>> Previously rxqs were assigned to pmds by round robin in
>> port/queue order.
>>
>> Now that we have the processing cycles used for existing rxqs,
>> use that information to try and produced a better balanced
>> distribution of rxqs across pmds. i.e. given multiple pmds, the
>> rxqs which have consumed the largest amount of processing cycles
>> will be placed on different pmds.
>>
>> The rxqs are sorted by their processing cycles and assigned (in
>> sorted order) round robin across pmds.
>>
>> Signed-off-by: Kevin Traynor 
>> ---
>>   Documentation/howto/dpdk.rst |  7 +
>>   lib/dpif-netdev.c| 73
>> +++-
>>   2 files changed, 66 insertions(+), 14 deletions(-)
>>
>> diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
>> index af01d3e..a969285 100644
>> --- a/Documentation/howto/dpdk.rst
>> +++ b/Documentation/howto/dpdk.rst
>> @@ -119,4 +119,11 @@ After that PMD threads on cores where RX queues
>> was pinned will become
>> thread.
>>
>> +If pmd-rxq-affinity is not set for rxqs, they will be assigned to
>> pmds (cores)
>> +automatically. The processing cycles that have been required for each
>> rxq
>> +will be used where known to assign rxqs with the highest consumption of
>> +processing cycles to different pmds.
>> +
>> +Rxq to pmds assignment takes place whenever there are configuration
>> changes.
>> +
>>   QoS
>>   ---
>> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
>> index 25a521a..a05e586 100644
>> --- a/lib/dpif-netdev.c
>> +++ b/lib/dpif-netdev.c
>> @@ -3295,8 +3295,29 @@ rr_numa_list_destroy(struct rr_numa_list *rr)
>>   }
>>
>> +/* Sort Rx Queues by the processing cycles they are consuming. */
>> +static int
>> +rxq_cycle_sort(const void *a, const void *b)
>> +{
>> +struct dp_netdev_rxq * qa;
>> +struct dp_netdev_rxq * qb;
>> +
>> +qa = *(struct dp_netdev_rxq **) a;
>> +qb = *(struct dp_netdev_rxq **) b;
>> +
>> +if (dp_netdev_rxq_get_cycles(qa, RXQ_CYCLES_PROC_LAST) >=
>> +dp_netdev_rxq_get_cycles(qb, RXQ_CYCLES_PROC_LAST)) {
>> +return -1;
>> +}
>> +
>> +return 1;
>> +}
>> +
>>   /* Assign pmds to queues.  If 'pinned' is true, assign pmds to pinned
>>* queues and marks the pmds as isolated.  Otherwise, assign non
>> isolated
>>* pmds to unpinned queues.
>>*
>> + * If 'pinned' is false queues will be sorted by processing cycles
>> they are
>> + * consuming and then assigned to pmds in round robin order.
>> + *
>>* The function doesn't touch the pmd threads, it just stores the
>> assignment
>>* in the 'pmd' member of each rxq. */
>> @@ -3306,18 +3327,14 @@ rxq_scheduling(struct dp_netdev *dp, bool
>> pinned) OVS_REQUIRES(dp->port_mutex)
>>   struct dp_netdev_port *port;
>>   struct rr_numa_list rr;
>> -
>> -rr_numa_list_populate(dp, );
>> +struct dp_netdev_rxq ** rxqs = NULL;
>> +int i, n_rxqs = 0;
>> +struct rr_numa *numa = NULL;
>> +int numa_id;
>>
>>   HMAP_FOR_EACH (port, node, >ports) {
>> -struct rr_numa *numa;
>> -int numa_id;
>> -
>>   if (!netdev_is_pmd(port->netdev)) {
>>   continue;
>>   }
>>
>> -numa_id = netdev_get_numa_id(port->netdev);
>> -numa = rr_numa_list_lookup(, numa_id);
>> -
>>   for (int qid = 0; qid < port->n_rxq; qid++) {
>>   struct dp_netdev_rxq *q = >rxqs[qid];
>> @@ -3337,17 +3354,45 @@ rxq_scheduling(struct dp_netdev *dp, bool
>> pinned) OVS_REQUIRES(dp->port_mutex)
>>   }
>>   } else if (!pinned && q->core_id == OVS_CORE_UNSPEC) {
>> -if (!numa) {
>> -VLOG_WARN("There's no available (non isolated)
>> pmd thread "
>> -  "on numa node %d. Queue %d on port
>> \'%s\' will "
>> -  "not be polled.",
>> -  numa_id, qid,
>> netdev_get_name(port->netdev));
>> +if (n_rxqs == 0) {
>> +rxqs = xmalloc(sizeof *rxqs);
>>   } else {
>> -q->pmd = rr_numa_get_pmd(numa);
>> +rxqs = xrealloc(rxqs, sizeof *rxqs * (n_rxqs + 1));
>>   }
>> +/* Store the queue. */
>> +rxqs[n_rxqs++] = q;
>>   }
>>   }
>>   }
>>
>> +if (n_rxqs > 1) {
>> +/* Sort the queues in order of the processing cycles
>> + * they consumed during their last pmd interval. */
>> +qsort(rxqs, n_rxqs, sizeof *rxqs, rxq_cycle_sort);
>> +}
>> +
>> +rr_numa_list_populate(dp, );
>> +/* Assign the sorted queues to pmds in round robin. */
>> +for (i = 0; i < n_rxqs; i++) {
>> +numa_id = netdev_get_numa_id(rxqs[i]->port->netdev);
>> +numa = rr_numa_list_lookup(, numa_id);
>> +if (!numa) 

[ovs-dev] [PATCH v4 1/6] dpif-netdev: Change polled_queue to use dp_netdev_rxq.

2017-08-09 Thread Kevin Traynor
Soon we will want to store processing cycle counts in the dp_netdev_rxq,
so use that as a basis for the polled_queue that pmd_thread_main uses.

Signed-off-by: Kevin Traynor 
---
 lib/dpif-netdev.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index e2cd931..f35c079 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -486,5 +486,5 @@ struct dp_netdev_pmd_cycles {
 
 struct polled_queue {
-struct netdev_rxq *rx;
+struct dp_netdev_rxq *rxq;
 odp_port_t port_no;
 };
@@ -3799,5 +3799,5 @@ pmd_load_queues_and_ports(struct dp_netdev_pmd_thread 
*pmd,
 i = 0;
 HMAP_FOR_EACH (poll, node, >poll_list) {
-poll_list[i].rx = poll->rxq->rx;
+poll_list[i].rxq = poll->rxq;
 poll_list[i].port_no = poll->rxq->port->port_no;
 i++;
@@ -3837,6 +3837,6 @@ reload:
 for (i = 0; i < poll_cnt; i++) {
VLOG_DBG("Core %d processing port \'%s\' with queue-id %d\n",
-pmd->core_id, netdev_rxq_get_name(poll_list[i].rx),
-netdev_rxq_get_queue_id(poll_list[i].rx));
+pmd->core_id, netdev_rxq_get_name(poll_list[i].rxq->rx),
+netdev_rxq_get_queue_id(poll_list[i].rxq->rx));
 }
 
@@ -3853,5 +3853,5 @@ reload:
 for (i = 0; i < poll_cnt; i++) {
 process_packets =
-dp_netdev_process_rxq_port(pmd, poll_list[i].rx,
+dp_netdev_process_rxq_port(pmd, poll_list[i].rxq->rx,
poll_list[i].port_no);
 cycles_count_intermediate(pmd,
-- 
1.8.3.1

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


Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum flags on init.

2017-08-09 Thread Ben Pfaff
On Tue, Aug 08, 2017 at 06:54:46PM -0700, Darrell Ball wrote:
> Reset the DPDK HWOL checksum flags in dp_packet_init_.
> The new HWOL bad checksum flag is uninitialized for non-dpdk ports and
> this is noticed as test failures using netdev-dummy ports, when built with
> the --with-dpdk flag set. Hence, in this case, packets may be marked as
> having a bad checksum.
> 
> Reported-at: 
> https://mail.openvswitch.org/pipermail/ovs-discuss/2017-August/045081.html
> Fixes: 7451af618e0d ("dp-packet : Update DPDK rx checksum validation 
> functions.")
> CC: Sugesh Chandran 
> Signed-off-by: Darrell Ball 
> ---
> 
> v3->v5: Update the commit message with more context.
> 
> v2->v3: Use existed API to reset both the DPDK HWOL flags.
> 
> v1->v2: Fix build failure for without --with-dpdk.
> 
>  lib/dp-packet.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/dp-packet.c b/lib/dp-packet.c
> index 67aa406..4926993 100644
> --- a/lib/dp-packet.c
> +++ b/lib/dp-packet.c
> @@ -31,6 +31,7 @@ dp_packet_init__(struct dp_packet *b, size_t allocated, 
> enum dp_packet_source so
>  dp_packet_reset_offsets(b);
>  pkt_metadata_init(>md, 0);
>  dp_packet_rss_invalidate(b);
> +reset_dp_packet_checksum_ol_flags(b);

This function un-sets some bits in p->mbuf.ol_flags.  The need for this
implies that nothing initializes p->mbuf.ol_flags.  That sounds like a
bug in itself--is there a missing call to initialize the mbuf somewhere?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum flags on init.

2017-08-09 Thread Ben Pfaff
On Wed, Aug 09, 2017 at 05:32:02PM +, Darrell Ball wrote:
> 
> 
> -Original Message-
> From:  on behalf of Ben Pfaff 
> Date: Wednesday, August 9, 2017 at 10:15 AM
> To: Darrell Ball 
> Cc: "d...@openvswitch.org" 
> Subject: Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum flags 
> on init.
> 
> On Tue, Aug 08, 2017 at 06:54:46PM -0700, Darrell Ball wrote:
> > Reset the DPDK HWOL checksum flags in dp_packet_init_.
> > The new HWOL bad checksum flag is uninitialized for non-dpdk ports and
> > this is noticed as test failures using netdev-dummy ports, when built 
> with
> > the --with-dpdk flag set. Hence, in this case, packets may be marked as
> > having a bad checksum.
>
> > diff --git a/lib/dp-packet.c b/lib/dp-packet.c
> > index 67aa406..4926993 100644
> > --- a/lib/dp-packet.c
> > +++ b/lib/dp-packet.c
> > @@ -31,6 +31,7 @@ dp_packet_init__(struct dp_packet *b, size_t 
> allocated, enum dp_packet_source so
> >  dp_packet_reset_offsets(b);
> >  pkt_metadata_init(>md, 0);
> >  dp_packet_rss_invalidate(b);
> > +reset_dp_packet_checksum_ol_flags(b);
> 
> This function un-sets some bits in p->mbuf.ol_flags.  The need for this
> implies that nothing initializes p->mbuf.ol_flags. 
> 
> Correct, I reused reset_dp_packet_checksum_ol_flags() to do the 
> initialization as well
> I could also have created a separate function.
> 
> In case a DPDK dev is used, those flags will be managed by DPDK.
>
>  That sounds like a
> bug in itself--is there a missing call to initialize the mbuf somewhere?
> 
> Are you suggesting to initialize the whole mbuf for each packet ?

The issue that I'm raising is that it's unusual to take an
uninitialized, indeterminate field, and then initialize it by clearing a
few bits.  It's much more conventional to initialize it by setting it to
zero, like this:

p->mbuf.ol_flags = 0;

That made me wonder whether there's a larger problem of a failure to
initialize the mbuf more generally, although of course that does not
necessarily follow.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] dp-packet: Use OVS_UNUSED to mark possibly unused parameters.

2017-08-09 Thread Darrell Ball
Acked-by: Darrell Ball 

-Original Message-
From:  on behalf of Ben Pfaff 
Date: Wednesday, August 9, 2017 at 10:43 AM
To: "d...@openvswitch.org" 
Cc: Ben Pfaff 
Subject: [ovs-dev] [PATCH] dp-packet: Use OVS_UNUSED to mark possibly unused
parameters.

This is the way usually used in OVS.

Signed-off-by: Ben Pfaff 
---
 lib/dp-packet.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/lib/dp-packet.h b/lib/dp-packet.h
index 9dbb611d95fb..8f52feeefa39 100644
--- a/lib/dp-packet.h
+++ b/lib/dp-packet.h
@@ -615,46 +615,46 @@ dp_packet_rss_invalidate(struct dp_packet *p)
 }
 
 static inline bool
-dp_packet_ip_checksum_valid(struct dp_packet *p)
+dp_packet_ip_checksum_valid(struct dp_packet *p OVS_UNUSED)
 {
 #ifdef DPDK_NETDEV
 return (p->mbuf.ol_flags & PKT_RX_IP_CKSUM_MASK) ==
 PKT_RX_IP_CKSUM_GOOD;
 #else
-return 0 && p;
+return false;
 #endif
 }
 
 static inline bool
-dp_packet_ip_checksum_bad(struct dp_packet *p)
+dp_packet_ip_checksum_bad(struct dp_packet *p OVS_UNUSED)
 {
 #ifdef DPDK_NETDEV
 return (p->mbuf.ol_flags & PKT_RX_IP_CKSUM_MASK) ==
 PKT_RX_IP_CKSUM_BAD;
 #else
-return 0 && p;
+return false;
 #endif
 }
 
 static inline bool
-dp_packet_l4_checksum_valid(struct dp_packet *p)
+dp_packet_l4_checksum_valid(struct dp_packet *p OVS_UNUSED)
 {
 #ifdef DPDK_NETDEV
 return (p->mbuf.ol_flags & PKT_RX_L4_CKSUM_MASK) ==
 PKT_RX_L4_CKSUM_GOOD;
 #else
-return 0 && p;
+return false;
 #endif
 }
 
 static inline bool
-dp_packet_l4_checksum_bad(struct dp_packet *p)
+dp_packet_l4_checksum_bad(struct dp_packet *p OVS_UNUSED)
 {
 #ifdef DPDK_NETDEV
 return (p->mbuf.ol_flags & PKT_RX_L4_CKSUM_MASK) ==
 PKT_RX_L4_CKSUM_BAD;
 #else
-return 0 && p;
+return false;
 #endif
 }
 
-- 
2.10.2

___
dev mailing list
d...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=0RZDgi3QSeTa-OACTsQTtSjiq06eE5_d3BVy9x27k0I=JFbjrYsebeV29PPEYqsW3vTei-H5PjvFb2Z1MaYTZYY=
 


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


Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support

2017-08-09 Thread Ben Pfaff
On Wed, Aug 09, 2017 at 09:41:51AM +, Yang, Yi Y wrote:
> Hi,  Jan
> 
> I have worked out a patch, will send it quickly for Ben. In addition, I also 
> will send out a patch to change encap_nsh _nsh to push_nsh and pop_nsh. 
> Per comments from all the people, we all agreed to do so :-)
> 
> diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
> b/datapath/linux/compat/include/linux/openvswitch.h
> index bc6c94b..4936c12 100644
> --- a/datapath/linux/compat/include/linux/openvswitch.h
> +++ b/datapath/linux/compat/include/linux/openvswitch.h
> @@ -793,7 +793,7 @@ struct ovs_action_push_eth {
> struct ovs_key_ethernet addresses;
>  };
> 
> -#define OVS_ENCAP_NSH_MAX_MD_LEN 16
> +#define OVS_ENCAP_NSH_MAX_MD_LEN 248
>  /*
>   * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
>   * @flags: NSH header flags.
> @@ -809,7 +809,7 @@ struct ovs_action_encap_nsh {
>  uint8_t mdlen;
>  uint8_t np;
>  __be32 path_hdr;
> -uint8_t metadata[OVS_ENCAP_NSH_MAX_MD_LEN];
> +uint8_t metadata[];
>  };

This brings the overall format of ovs_action_encap_nsh to:

struct ovs_action_encap_nsh {
uint8_t flags;
uint8_t mdtype;
uint8_t mdlen;
uint8_t np;
__be32 path_hdr;
uint8_t metadata[];
};

This is an unusual format for a Netlink attribute.  More commonly, one
would put variable-length data into an attribute of its own, which
allows that data to be handled using the regular Netlink means.  Then
the mdlen and metadata members could be removed, since they would be
part of the additional attribute, and one might expect the mdtype member
to be removed as well since each type of metadata would be in a
different attribute type.

So, a format closer to what I expect to see in Netlink is something like
this:

/**
 * enum ovs_nsh_attr - Metadata attributes for %OVS_ACTION_ENCAP_NSH action.
 *
 * @OVS_NSH_ATTR_MD1: Contains 16-byte NSH type-1 metadata.
 * @OVS_NSH_ATTR_MD2: Contains 0- to 255-byte variable-length NSH type-2
 * metadata. */
enum ovs_nsh_attr {
OVS_NSH_ATTR_MD1,
OVS_NSH_ATTR_MD2
};

/*
 * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
 *
 * @path_hdr: NSH service path id and service index.
 * @flags: NSH header flags.
 * @np: NSH next_protocol: Inner packet type.
 *
 * Followed by either %OVS_NSH_ATTR_MD1 or %OVS_NSH_ATTR_MD2 attribute.
 */
struct ovs_action_encap_nsh {
__be32 path_hdr;
uint8_t flags;
uint8_t np;
};
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v5 2/3] ovn-controller: Add a new action - 'put_nd_ra_opts'

2017-08-09 Thread Ben Pfaff
On Fri, Aug 04, 2017 at 04:09:58PM +0530, Numan Siddique wrote:
> On Fri, Aug 4, 2017 at 3:02 AM, Ben Pfaff  wrote:
> 
> > On Mon, Jul 31, 2017 at 06:11:35PM +0530, nusid...@redhat.com wrote:
> > > From: Numan Siddique 
> > >
> > > This patch adds a new OVN action 'put_nd_ra_opts' to support native
> > > IPv6 Router Advertisement in OVN. This action can be used to respond
> > > to the IPv6 Router Solicitation requests.
> > >
> > > ovn-controller parses this action and adds a NXT_PACKET_IN2 OF flow
> > > with 'pause' flag set and the RA options stored in 'userdata' field.
> > > This action is similar to 'put_dhcp_opts' and 'put_dhcpv6_opts'.
> > >
> > > When a valid IPv6 RS packet is received by the pinctrl module of
> > > ovn-controller, it frames a new RA packet and sets the RA options
> > > from the 'userdata' field and resumes the packet storing 1 in the
> > > 1-bit result sub-field. If the packet is invalid, it resumes the
> > > packet without any modifications storing 0 in the 1-bit result
> > > sub-field.
> > >
> > > Eg. reg0[5] = put_nd_ra_opts(address_mode = "slaac", mtu = 1450,
> > >  slla = 01:02:03:04:05:06, prefix =
> > aef0::/64)
> > >
> > > Note that unlike DHCPv4/v6, a new table to store the supported IPv6 ND RA
> > > options is not added in SB DB since there are only 3 ND RA options.
> > >
> > > Co-authored-by: Zongkai LI 
> > > Signed-off-by: Zongkai LI 
> > > Signed-off-by: Numan Siddique 
> > > Acked-by: Miguel Angel Ajo 
> >
> > Thanks for working on this.
> >
> > Looking at it, the treatment of some of the options strikes me as odd.
> > Some of the options (SLL) are actually required, and others could be
> > supplied as fixed data since there's a default value (mo_flags, mtu).
> > Only the prefixes seem to really be options in what I think of as the
> > usual sense.  It looks to me like those prefixes could be supplied
> > directly in the userdata as bytes to append to the packet.  It might be
> > cleaner to make these changes--then there would be less parsing of text
> > options, encoding them as binary options, decoding those binary options,
> > and then re-encoding them again in the packet.
> >
> >
> Thanks for the review Ben. I think what you are suggesting makes sense and
> simplies the code. Based on your comments, this is what I am planning to
> modify this patch.
> 
> "put_nd_ra_opts" action would be like
> 
> res_bit = put_nd_ra_opts(slla, mtu, mo_flags, ...)
> 
>  ovn-northd would include 0 or more prefixes following the mo_flags field
> depending the address mode defined by the user.
> 
> Eg.
> reg0[4] = put_nd_ra_opts(01:02:03:04:05:06, 1450, 0, aef0::/64)
> reg0[4] = put_nd_ra_opts(01:02:03:04:05:06, 1450, 64, aef0::/64, bef0::/64)
> reg0[4] = put_nd_ra_opts(01:02:03:04:05:06, 1450, 128)
> 
> 
> If this makes sense, I will update the patches accordingly. Please let me
> know.

That is one reasonable option, but it is not what I had in mind.  I like
put_nd_ra_opts() syntax because it is very clear, so my thought was to
retain that syntax and change only the format of the data sent to
ovn-controller.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] Starting point for extending OVS

2017-08-09 Thread Chui Hui Chiu
Hello,

We are students trying to extend OVS in the Linux environment for our
research works.  We have primitive understandings of OVS after reading the
documents.  However, we are uncertain whether we are on the adequate
track.  The new features of our design and our speculated starting points
are

1)
Feature
Collecting statistics (e.g. total bytes transferred) at each switch port.

Speculated starting point
netdev_linux_get_stats() in lib/netdev-linux.c

2)
Feature
Post processing statistics collected in (1).

Speculated starting point
lib/dpif-netlink.c
Adding our algorithm.

3)
Feature
In-band exchange of processed statistics in (2) between OVSs.

Speculated starting point
lib/dpif-netlink.c
We still do not know how to inject our own control packets into datapath.
Do we have to trace how OVS processes the "PACKET_OUT" OpenFlow message?

4)
Feature
Good performance comparable to original OVS.

Speculated starting point
lib/dpif-netlink.c and datapath/datapath.c
Customizing existing dpif to call only kernel-level functions in datapath/
to achieve (1), (2), and (3).

Please give your valuable suggestions and comments.

Many thanks in advance!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] ovs-vsctl-bashcomp: Make compatible with busybox "awk".

2017-08-09 Thread Ben Pfaff
On Fri, Aug 04, 2017 at 09:54:26AM -0400, Lance Richardson wrote:
> > From: "Ben Pfaff" 
> > To: d...@openvswitch.org
> > Cc: "Ben Pfaff" , "Stuart Cardall" 
> > 
> > Sent: Friday, 14 July, 2017 12:42:54 AM
> > Subject: [ovs-dev] [PATCH] ovs-vsctl-bashcomp: Make compatible with busybox 
> > "awk".
> > 
> > It seems that awk in busybox doesn't think that an empty string is part of
> > a larger string, but that GNU awk does.  This commit adds an extra test to
> > make _ovs_vsctl_check_startswith_string work either way.
> > 
> > This allows the following tests to pass with busybox awk:
> > 
> > vsctl bashcomp unit tests
> > 
> >   7: vsctl-bashcomp - basic verification ok
> >   8: vsctl-bashcomp - argument completionok
> > 
> > Reported-by: Stuart Cardall 
> > Signed-off-by: Ben Pfaff 
> > ---
> 
> Makes sense, verified that these test cases now pass in the Alpine
> environment with busybox awk.
> 
> Acked-by: Lance Richardson 

Thanks for the review.  I applied this to master and branch-2.8.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v1] netdev-dpdk: Implement TCP/UDP TX cksum in ovs-dpdk side

2017-08-09 Thread Gao Zhenyu
I see, for flows in phy-phy setup, they should not be calculate cksum.
I will revise my patch to do the cksum for vhost port only. I will send a
new patch next week.

Thanks
Zhenyu Gao

2017-08-08 17:53 GMT+08:00 Loftus, Ciara :

> >
> > Hi Loftus,
> >
> > Thanks for testing and the comments!
> > Can you show more details about your phy-vm-phy,phy-phy setup and
> > testing steps? Then I can reproduce it to see if I can solve this pps
> problem.
>
> You're welcome. I forgot to mention my tests were with 64B packets.
>
> For phy-phy the setup is a single host with 2 dpdk physical ports and 1
> flow rule port1 -> port2.
> See figure 3 here: https://tools.ietf.org/html/
> draft-ietf-bmwg-vswitch-opnfv-04#section-4
>
> For the phy-vm-phy the setup is a single host with 2 dpdk physical ports
> and 2 vhostuser ports with flow rules:
> Dpdk1 -> vhost 1 & vhost2 -> dpdk2
> IP rules are set up in the VM to route packets from vhost1 to vhost 2.
> See figure 4 in the link above.
>
> >
> > BTW, how about throughput, did you saw improvment?
>
> By throughput if you mean 0% packet loss, I did not test this.
>
> Thanks,
> Ciara
>
> >
> > I would like to implement vhost->vhost part.
> >
> > Thanks
> > Zhenyu Gao
> >
> > 2017-08-04 22:52 GMT+08:00 Loftus, Ciara :
> > >
> > > Currently, the dpdk-vhost side in ovs doesn't support tcp/udp tx cksum.
> > > So L4 packets's cksum were calculated in VM side but performance is not
> > > good.
> > > Implementing tcp/udp tx cksum in ovs-dpdk side improves throughput and
> > > makes virtio-net frontend-driver support NETIF_F_SG as well
> > >
> > > Signed-off-by: Zhenyu Gao 
> > > ---
> > >
> > > Here is some performance number:
> > >
> > > Setup:
> > >
> > >  qperf client
> > > +-+
> > > |   VM|
> > > +-+
> > >  |
> > >  |  qperf server
> > > +--+  ++
> > > | vswitch+dpdk |  | bare-metal |
> > > +--+  ++
> > >||
> > >||
> > >   pNic-PhysicalSwitch
> > >
> > > do cksum in ovs-dpdk: Applied this patch and execute 'ethtool -K eth0
> tx
> > on'
> > > in VM side.
> > >   It offload cksum job to ovs-dpdk side.
> > >
> > > do cksum in VM: Applied this patch and execute 'ethtool -K eth0 tx
> off' in
> > VM
> > > side.
> > > VM calculate cksum for tcp/udp packets.
> > >
> > > We can see huge improvment in TCP throughput if we leverage ovs-dpdk
> > > cksum.
> > Hi Zhenyu,
> >
> > Thanks for the patch. I tested some alternative use cases and
> unfortunately I
> > see a degradation for phy-phy and phy-vm-phy topologies.
> > Here are my results:
> >
> > phy-vm-phy:
> > without patch: 0.871Mpps
> > with patch (offload=on): 0.877Mpps
> > with patch (offload=off): 0.891Mpps
> >
> > phy-phy:
> > without patch: 13.581Mpps
> > with patch: 13.055Mpps
> >
> > The half a million pps drop for the second test case is concerning to me
> but
> > not surprising since we're adding extra complexity to netdev_dpdk_send()
> > Could this be avoided? Would it make sense to put this functionality
> > somewhere else eg. vhost receive?
> >
> > On another note I have a general concern. I understand similar
> functionality
> > is present in the DPDK vhost sample app. I wonder if it would be
> feasible for
> > this to be implemented in the DPDK vhost library and leveraged here,
> rather
> > than having two implementations in two separate code bases.
> >
> > I have some other comments inline.
> >
> > Thanks,
> > Ciara
> >
> > >
> > > [root@localhost ~]# qperf -t 10 -oo msg_size:1:64K:*2
> host-qperf-server01
> > > tcp_bw tcp_lat udp_bw udp_lat
> > >   do cksum in ovs-dpdk  do cksum in VM without
> this patch
> > > tcp_bw:
> > > bw  =  2.05 MB/secbw  =  1.92 MB/secbw  =  1.95
> MB/sec
> > > tcp_bw:
> > > bw  =  3.9 MB/sec bw  =  3.99 MB/secbw  =  3.98
> MB/sec
> > > tcp_bw:
> > > bw  =  8.09 MB/secbw  =  7.82 MB/secbw  =  8.19
> MB/sec
> > > tcp_bw:
> > > bw  =  14.9 MB/secbw  =  14.8 MB/secbw  =  15.7
> MB/sec
> > > tcp_bw:
> > > bw  =  27.7 MB/secbw  =  28 MB/sec  bw  =  29.7
> MB/sec
> > > tcp_bw:
> > > bw  =  51.2 MB/secbw  =  50.9 MB/secbw  =  54.9
> MB/sec
> > > tcp_bw:
> > > bw  =  86.7 MB/secbw  =  86.8 MB/secbw  =  95.1
> MB/sec
> > > tcp_bw:
> > > bw  =  149 MB/sec bw  =  160 MB/sec bw  =  149
> MB/sec
> > > tcp_bw:
> > > bw  =  211 MB/sec bw  =  205 MB/sec bw  =  216
> MB/sec
> > > tcp_bw:
> > > bw  =  271 MB/sec bw  =  254 MB/sec bw  =  275
> MB/sec
> > > tcp_bw:
> > > bw  =  326 MB/sec bw  =  303 MB/sec bw  =  321
> MB/sec
> > > tcp_bw:
> > > bw  

Re: [ovs-dev] [PATCHv2 1/4] ovsdb-idl: Avoid class declaration.

2017-08-09 Thread Gao Zhenyu
How about:
struct ovsdb_idl_table {
...
const struct ovsdb_idl_table_class *table_class

}

struct ovsdb_idl {

 const struct ovsdb_idl_class *idl_class;


Besides of that, I see many places consume the table class.
Do you mind to make a macro helps to fetch the class?
Like:

#define OVSDB_GET_TABLE_CLASS(row) \
((row)->table->class)

Thanks
Zhenyu Gao

2017-08-10 6:27 GMT+08:00 Joe Stringer :

> In C++, 'class' is a keyword. If this is used as the name for a field,
> then C++ compilers can get confused about the context and fail to
> compile references to such fields. Rename the field to 'class_' to
> avoid this issue.
>
> Signed-off-by: Joe Stringer 
> ---
> v2: Rebase.
> ---
>  lib/db-ctl-base.c|   4 +-
>  lib/ovsdb-idl-provider.h |   2 +-
>  lib/ovsdb-idl.c  | 154 +++---
> -
>  3 files changed, 80 insertions(+), 80 deletions(-)
>
> diff --git a/lib/db-ctl-base.c b/lib/db-ctl-base.c
> index d597c6c2af6f..9fec6fa0d59e 100644
> --- a/lib/db-ctl-base.c
> +++ b/lib/db-ctl-base.c
> @@ -635,7 +635,7 @@ check_mutable(const struct ovsdb_idl_row *row,
>  {
>  if (!ovsdb_idl_is_mutable(row, column)) {
>  ctl_fatal("cannot modify read-only column %s in table %s",
> -  column->name, row->table->class->name);
> +  column->name, row->table->class_->name);
>  }
>  }
>
> @@ -1715,7 +1715,7 @@ cmd_show_find_table_by_row(const struct
> ovsdb_idl_row *row)
>  const struct cmd_show_table *show;
>
>  for (show = cmd_show_tables; show->table; show++) {
> -if (show->table == row->table->class) {
> +if (show->table == row->table->class_) {
>  return show;
>  }
>  }
> diff --git a/lib/ovsdb-idl-provider.h b/lib/ovsdb-idl-provider.h
> index 59fb24015904..a2eb8cac67d7 100644
> --- a/lib/ovsdb-idl-provider.h
> +++ b/lib/ovsdb-idl-provider.h
> @@ -104,7 +104,7 @@ struct ovsdb_idl_table_class {
>  };
>
>  struct ovsdb_idl_table {
> -const struct ovsdb_idl_table_class *class;
> +const struct ovsdb_idl_table_class *class_;
>  unsigned char *modes;/* OVSDB_IDL_* bitmasks, indexed by column.
> */
>  bool need_table; /* Monitor table even if no columns are
> selected
>* for replication. */
> diff --git a/lib/ovsdb-idl.c b/lib/ovsdb-idl.c
> index e916e940b652..227aa5fbfcb2 100644
> --- a/lib/ovsdb-idl.c
> +++ b/lib/ovsdb-idl.c
> @@ -89,11 +89,11 @@ enum ovsdb_idl_state {
>  };
>
>  struct ovsdb_idl {
> -const struct ovsdb_idl_class *class;
> +const struct ovsdb_idl_class *class_;
>  struct jsonrpc_session *session;
>  struct uuid uuid;
>  struct shash table_by_name; /* Contains "struct ovsdb_idl_table *"s.*/
> -struct ovsdb_idl_table *tables; /* Array of ->class->n_tables
> elements. */
> +struct ovsdb_idl_table *tables; /* Array of ->class_->n_tables
> elements. */
>  unsigned int change_seqno;
>  bool verify_write_only;
>
> @@ -270,7 +270,7 @@ ovsdb_idl_create(const char *remote, const struct
> ovsdb_idl_class *class,
>  : 0);
>
>  idl = xzalloc(sizeof *idl);
> -idl->class = class;
> +idl->class_ = class;
>  idl->session = jsonrpc_session_open(remote, retry);
>  shash_init(>table_by_name);
>  idl->tables = xmalloc(class->n_tables * sizeof *idl->tables);
> @@ -280,7 +280,7 @@ ovsdb_idl_create(const char *remote, const struct
> ovsdb_idl_class *class,
>  size_t j;
>
>  shash_add_assert(>table_by_name, tc->name, table);
> -table->class = tc;
> +table->class_ = tc;
>  table->modes = xmalloc(tc->n_columns);
>  memset(table->modes, default_mode, tc->n_columns);
>  table->need_table = false;
> @@ -338,7 +338,7 @@ ovsdb_idl_destroy(struct ovsdb_idl *idl)
>  ovsdb_idl_clear(idl);
>  jsonrpc_session_close(idl->session);
>
> -for (i = 0; i < idl->class->n_tables; i++) {
> +for (i = 0; i < idl->class_->n_tables; i++) {
>  struct ovsdb_idl_table *table = >tables[i];
>  ovsdb_idl_condition_destroy(>condition);
>  ovsdb_idl_destroy_indexes(table);
> @@ -363,7 +363,7 @@ ovsdb_idl_clear(struct ovsdb_idl *idl)
>  bool changed = false;
>  size_t i;
>
> -for (i = 0; i < idl->class->n_tables; i++) {
> +for (i = 0; i < idl->class_->n_tables; i++) {
>  struct ovsdb_idl_table *table = >tables[i];
>  struct ovsdb_idl_row *row, *next_row;
>
> @@ -768,9 +768,9 @@ ovsdb_idl_check_consistency(const struct ovsdb_idl
> *idl)
>  struct uuid *dsts = NULL;
>  size_t allocated_dsts = 0;
>
> -for (size_t i = 0; i < idl->class->n_tables; i++) {
> +for (size_t i = 0; i < idl->class_->n_tables; i++) {
>  const struct ovsdb_idl_table *table = >tables[i];
> -const struct ovsdb_idl_table_class *class = table->class;
> +const struct 

Re: [ovs-dev] [PATCHv2 2/4] ovsdb-idl: Avoid mutable type specifier.

2017-08-09 Thread Gao Zhenyu
How about mutable --> is_mutable ?


Thanks
Zhenyu Gao

2017-08-10 6:27 GMT+08:00 Joe Stringer :

> In C++, 'mutable' is a keyword. If this is used as the name for a field,
> then C++ compilers can get confused about the context and fail to
> compile references to such fields. Rename the field to 'mutable_' to
> avoid this issue.
>
> Signed-off-by: Joe Stringer 
> ---
> v2: Rebase.
> ---
>  lib/ovsdb-idl-provider.h | 2 +-
>  lib/ovsdb-idl.c  | 2 +-
>  ovsdb/ovsdb-idlc.in  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/lib/ovsdb-idl-provider.h b/lib/ovsdb-idl-provider.h
> index a2eb8cac67d7..aa1fa9390572 100644
> --- a/lib/ovsdb-idl-provider.h
> +++ b/lib/ovsdb-idl-provider.h
> @@ -89,7 +89,7 @@ struct ovsdb_idl_row {
>  struct ovsdb_idl_column {
>  char *name;
>  struct ovsdb_type type;
> -bool mutable;
> +bool mutable_;
>  void (*parse)(struct ovsdb_idl_row *, const struct ovsdb_datum *);
>  void (*unparse)(struct ovsdb_idl_row *);
>  };
> diff --git a/lib/ovsdb-idl.c b/lib/ovsdb-idl.c
> index 227aa5fbfcb2..d474075fa990 100644
> --- a/lib/ovsdb-idl.c
> +++ b/lib/ovsdb-idl.c
> @@ -2871,7 +2871,7 @@ bool
>  ovsdb_idl_is_mutable(const struct ovsdb_idl_row *row,
>   const struct ovsdb_idl_column *column)
>  {
> -return column->mutable || (row->new && !row->old);
> +return column->mutable_ || (row->new && !row->old);
>  }
>
>  /* Returns false if 'row' was obtained from the IDL, true if it was
> initialized
> diff --git a/ovsdb/ovsdb-idlc.in b/ovsdb/ovsdb-idlc.in
> index f065ef1c68fe..36b7d2700bb6 100755
> --- a/ovsdb/ovsdb-idlc.in
> +++ b/ovsdb/ovsdb-idlc.in
> @@ -1268,7 +1268,7 @@ void
>   .type = {
>  %(type)s
>   },
> - .mutable = %(mutable)s,
> + .mutable_ = %(mutable)s,
>   .parse = %(s)s_parse_%(c)s,
>   .unparse = %(s)s_unparse_%(c)s,
>  },\n""" % {'P': prefix.upper(),
> --
> 2.13.3
>
> ___
> 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] DPDK build errors on travis

2017-08-09 Thread Darrell Ball


-Original Message-
From: Ben Pfaff 
Date: Tuesday, August 8, 2017 at 11:22 AM
To: Darrell Ball 
Cc: "d...@openvswitch.org" 
Subject: Re: [ovs-dev] DPDK build errors on travis

Yes, travis is switching.  We need to adapt to it sooner or later.  It
is possible that the best solution here is to disable the particular
warning, for example by adding -Wno-error=inline to some appropriate
CFLAGS.

I tried a few approaches…
-Wno-error=inline worked
Thanks

Or maybe this line in linux-build.sh needs adjustment:
find ./ -type f | xargs sed -i 
's/max-inline-insns-single=100/max-inline-insns-single=400/'




On Tue, Aug 08, 2017 at 05:09:17PM +, Darrell Ball wrote:
> We ran these builds many times with 17.05.1 and they were fine.
> Is Travis switching over to a new build environment ?
> 
> I saw a notification
> 
> “This job ran on our Trusty environment, which is gradually becoming our 
default Linux environment. Read all about this in our blog: Trusty as a default 
Linux is coming and take note that you can add dist: precise in your 
.travis.yml file to continue using Precise.”
> 
> 
> 
> 
> 
> -Original Message-
> From:  on behalf of Ben Pfaff 

> Date: Tuesday, August 8, 2017 at 10:01 AM
> To: "d...@openvswitch.org" 
> Subject: [ovs-dev] DPDK build errors on travis
> 
> The travis builds with DPDK enabled and kernel 3.16.46
> (e.g. 
https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_openvswitch_ovs_jobs_262034416=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=f9mUm5fLWvW1BWsgzQdwLeGoXH_2sG-pQAmCnB2sHGA=mvpkSBHpwq4BM3KdvUVO7wnd_x7WCMnVQTy82wXdJSo=
 ) are failing
> with the following errors:
> 
> = Build lib/librte_eal/linuxapp/igb_uio
> make[1]: Entering directory 
`/home/travis/build/openvswitch/ovs/linux-3.16.46'
>   WARNING: Symbol version dump ./Module.symvers
>is missing; modules will have no dependencies and 
modversions.
>   LD  
/home/travis/build/openvswitch/ovs/dpdk-stable-17.05.1/build/build/lib/librte_eal/linuxapp/igb_uio/built-in.o
>   CC [M]  
/home/travis/build/openvswitch/ovs/dpdk-stable-17.05.1/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o
> In file included from 
/home/travis/build/openvswitch/ovs/linux-3.16.46/include/linux/dma-mapping.h:82:0,
>  from 
/home/travis/build/openvswitch/ovs/linux-3.16.46/include/asm-generic/pci-dma-compat.h:7,
>  from 
/home/travis/build/openvswitch/ovs/linux-3.16.46/arch/x86/include/asm/pci.h:118,
>  from 
/home/travis/build/openvswitch/ovs/linux-3.16.46/include/linux/pci.h:1420,
>  from 
/home/travis/build/openvswitch/ovs/dpdk-stable-17.05.1/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.c:29:
> 
/home/travis/build/openvswitch/ovs/linux-3.16.46/arch/x86/include/asm/dma-mapping.h:
 In function ‘igbuio_pci_probe’:
> 
/home/travis/build/openvswitch/ovs/linux-3.16.46/arch/x86/include/asm/dma-mapping.h:32:35:
 error: inlining failed in call to ‘get_dma_ops’: call is unlikely and code 
size would grow [-Werror=inline]
>  static inline struct dma_map_ops *get_dma_ops(struct device *dev)
>^
> In file included from 
/home/travis/build/openvswitch/ovs/linux-3.16.46/include/linux/dma-mapping.h:82:0,
>  from 
/home/travis/build/openvswitch/ovs/linux-3.16.46/include/asm-generic/pci-dma-compat.h:7,
>  from 
/home/travis/build/openvswitch/ovs/linux-3.16.46/arch/x86/include/asm/pci.h:118,
>  from 
/home/travis/build/openvswitch/ovs/linux-3.16.46/include/linux/pci.h:1420,
>  from 
/home/travis/build/openvswitch/ovs/dpdk-stable-17.05.1/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.c:29:
> 
/home/travis/build/openvswitch/ovs/linux-3.16.46/arch/x86/include/asm/dma-mapping.h:134:22:
 error: called from here [-Werror=inline]
>   struct dma_map_ops *ops = get_dma_ops(dev);
>   ^
> In file included from 
/home/travis/build/openvswitch/ovs/linux-3.16.46/include/linux/dma-mapping.h:82:0,
>  from 
/home/travis/build/openvswitch/ovs/linux-3.16.46/include/asm-generic/pci-dma-compat.h:7,
>  from 
/home/travis/build/openvswitch/ovs/linux-3.16.46/arch/x86/include/asm/pci.h:118,
>  from 
/home/travis/build/openvswitch/ovs/linux-3.16.46/include/linux/pci.h:1420,
>  from 
/home/travis/build/openvswitch/ovs/dpdk-stable-17.05.1/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.c:29:
> 

[ovs-dev] [PATCH v3] route-table: Remove netdevs in netdev_hash when deleted

2017-08-09 Thread fukaige
From: Kaige Fu 

Start a virtual machine with its backend tap device attached to a brought up 
linux bridge.
If we delete the linux bridge when vm is still running, we'll get the following 
error when
trying to create a ovs bridge with the same name.

The reason is that ovs-router subsystem add the linux bridge into netdev_shash, 
but does
not remove it when the bridge is deleted in the situation. When the bridge is 
deleted, ovs
will receive a RTM_DELLINK msg, take this chance to remove the bridge in 
netdev_shash.

ovs-vsctl: Error detected while setting up 'br-eth'.  See ovs-vswitchd log for 
details.

ovs-vswitchd log:
2017-05-11T03:45:25.293Z|00026|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports recirculation
2017-05-11T03:45:25.293Z|00027|ofproto_dpif|INFO|system@ovs-system: MPLS label 
stack length probed as 1
2017-05-11T03:45:25.293Z|00028|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports unique flow ids
2017-05-11T03:45:25.293Z|00029|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports ct_state
2017-05-11T03:45:25.293Z|00030|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports ct_zone
2017-05-11T03:45:25.293Z|00031|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports ct_mark
2017-05-11T03:45:25.293Z|00032|ofproto_dpif|INFO|system@ovs-system: Datapath 
supports ct_label
2017-05-11T03:45:25.364Z|1|ofproto_dpif_upcall(handler226)|INFO|received 
packet on unassociated datapath port 0
2017-05-11T03:45:25.368Z|00033|netdev_linux|WARN|ethtool command ETHTOOL_GFLAGS 
on network device br-eth failed: No such device
2017-05-11T03:45:25.368Z|00034|dpif|WARN|system@ovs-system: failed to add 
br-eth as port: No such device
2017-05-11T03:45:25.368Z|00035|bridge|INFO|bridge br-eth: using datapath ID 
2a51cf9f2841
2017-05-11T03:45:25.368Z|00036|connmgr|INFO|br-eth: added service controller 
"punix:/var/run/openvswitch/br-eth.mgmt"

Signed-off-by: Kaige Fu 
---
 lib/route-table.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/lib/route-table.c b/lib/route-table.c
index 67fda31..5107056 100644
--- a/lib/route-table.c
+++ b/lib/route-table.c
@@ -33,6 +33,7 @@
 #include "ovs-router.h"
 #include "packets.h"
 #include "rtnetlink.h"
+#include "tnl-ports.h"
 #include "openvswitch/vlog.h"
 
 /* Linux 2.6.36 added RTA_MARK, so define it just in case we're building with
@@ -79,6 +80,7 @@ static int route_table_reset(void);
 static void route_table_handle_msg(const struct route_table_msg *);
 static int route_table_parse(struct ofpbuf *, struct route_table_msg *);
 static void route_table_change(const struct route_table_msg *, void *);
+static void route_table_link_del(const struct rtnetlink_change *, void *);
 static void route_map_clear(void);
 
 static void name_table_init(void);
@@ -112,6 +114,8 @@ route_table_init(void)
 nln_notifier_create(nln, RTNLGRP_IPV6_ROUTE,
 (nln_notify_func *) route_table_change, NULL);
 
+rtnetlink_notifier_create(route_table_link_del, NULL);
+
 route_table_reset();
 name_table_init();
 
@@ -297,6 +301,17 @@ route_table_change(const struct route_table_msg *change 
OVS_UNUSED,
 }
 
 static void
+route_table_link_del(const struct rtnetlink_change *change,
+ void *aux OVS_UNUSED)
+{
+if(change && change->nlmsg_type == RTM_DELLINK) {
+if(change->ifname) {
+tnl_port_map_delete_ipdev(change->ifname);
+}
+}
+}
+
+static void
 route_table_handle_msg(const struct route_table_msg *change)
 {
 if (change->relevant && change->nlmsg_type == RTM_NEWROUTE) {
-- 
1.8.3.1


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


Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support

2017-08-09 Thread Jan Scheurich
Hi all,

In OVS 2.8 we support only fixed size NSH MD1 context data for matching and in 
set/copy_field actions. OVS parses an MD2 NSH header but does not make any TLV 
headers available to OF. The plan is to add support for matching/manipulating 
NSH MD2 TLVs through a new infrastructure of generic TLV match fields that can 
be dynamically mapped to specific protocol TLVs, similar to the way this is 
done for GENEVE tunnel metadata TLVs today. But this is work for an upcoming 
OVS release.

However, in encap() and decap() NSH actions we do support MD2 format already. 
The encap_nsh datapath action is agnostic of the MD format. Any MD2 TLV 
metadata are provided as encap properties in the OF encap() operation. They are 
translated by the ofproto layer and forwarded as opaque byte sequence in the 
encap_nsh datapath action.

Conversely, the decap_nsh() action pops any TLV metadata using the metadata 
length in the NSH header.

Consequently the datapath action OVS_ACTION_ATTR_ENCAP_NSH is already declared 
variable length:

odp_action_len(uint16_t type)
{
switch ((enum ovs_action_attr) type) {
...
case OVS_ACTION_ATTR_ENCAP_NSH: return ATTR_LEN_VARIABLE;
case OVS_ACTION_ATTR_DECAP_NSH: return 0;
...
}

Unfortunately, that has only partially been reflected in the rest of the code. 
The action struct should have a variable length metadata[] member and the 
function odp_put_encap_nsh_action() should set the action nl_attr length 
dynamically.

I'll provide a patch to fix that shortly.

BTW: I have no objections to renaming these datapath actions to push_nsh and 
pop_nsh if that helps avoiding confusion with the existing encap attributes on 
the netlink interface. But we should do that quickly as it is user-visible and 
affects unit test cases.

BR, Jan


> -Original Message-
> From: ovs-dev-boun...@openvswitch.org 
> [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Ben Pfaff
> Sent: Wednesday, 09 August, 2017 04:42
> To: Yang, Yi Y 
> Cc: d...@openvswitch.org; net...@vger.kernel.org; Jiri Benc 
> ; da...@davemloft.net
> Subject: Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support
> 
> To be clear, the OVS implementation is a placeholder.  It will get
> replaced by whatever netdev implements, and that's OK.  I didn't focus
> on making it perfect because I knew that.  Instead, I just made sure it
> was good enough for an internal OVS implementation that doesn't fix any
> ABI or API.  OVS can even change the user-visible action names, as long
> as we do that soon (and encap/decap versus push/pop doesn't matter to
> me).
> 
> The considerations for netdev are different and more permanent.
> 
> On Wed, Aug 09, 2017 at 02:05:12AM +, Yang, Yi Y wrote:
> > Hi, Jiri
> >
> > Thank you for your comments.
> >
> > __be32 c[4] is the name Ben Pfaff suggested, the original name is c1, c2, 
> > c3, c4, they are context data, so c seems ok, too :-)
> >
> > OVS has merged it and has the same name, maybe the better way is adding 
> > comment /* Context data */ after it.
> >
> > For MD type 2, struct ovs_key_nsh is very difficult to cover it, so far we 
> > don't know how to support MD type 2 better, Geneve defined 64
> tun_metadata0-63 to handle this, those keys are parts of struct flow_tnl, the 
> highest possibility is to reuse those keys.
> >
> > So for future MD type 2, we will have two parts of keys, one is from struct 
> > ovs_key_nsh, another is from struct flow_tnl, this won't break
> the old uAPI.
> >
> > "#define OVS_ENCAP_NSH_MAX_MD_LEN 16" is changed per Ben's comment from 
> > 256, Ben thinks 256 is too big but we only support
> MD type 1 now. We still have ways to extend it, for example:
> >
> > struct ovs_action_encap_nsh * oaen = (struct ovs_action_encap_nsh *) malloc 
> > (sizeof(struct ovs_action_encap_nsh) + ANY_SIZE);
> >
> > nl_msg_put_unspec(actions, OVS_ACTION_ATTR_ENCAP_NSH,
> >   oaen, sizeof(struct ovs_action_encap_nsh) + 
> > ANY_SIZE);
> >
> > In addition, we also need to consider, OVS userspace code must be 
> > consistent with here, so keeping it intact will be better, we have way
> to support dynamically extension when we add MD type 2 support.
> >
> > About action name, unfortunately, userspace data plane has named them as 
> > encap_nsh & decap_nsh, Jan, what do you think about Jiri's
> suggestion?
> >
> > But from my understanding, encap_* & decap_* are better because they 
> > corresponding to generic encap & decap actions, in addition,
> encap semantics are different from push, encap just pushed an empty header 
> with default values, users must use set_field to set the
> content of the header.
> >
> > Again, OVS userspace code must be consistent with here, so keeping it 
> > intact will be better because OVS userspace code was there.
> >
> >
> > -Original Message-
> > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On 
> > Behalf Of Jiri Benc
> > Sent: Tuesday, 

[ovs-dev] [patch_v1] travis: Fix DPDK builds in new environment.

2017-08-09 Thread Darrell Ball
The following error is seen:
17.05.1/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.c:29:
/home/travis/build/darball/ovs/linux-3.16.46/arch/x86/include/asm/
dma-mapping.h:32:35: error: inlining failed in call to ‘get_dma_ops’:
call is unlikely and code size would grow [-Werror=inline]

-Wno-error=inline is used to address the issues with
the new environment.

Suggested-by: Ben Pfaff 
Signed-off-by: Darrell Ball 
---
 .travis/linux-build.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index efccdf1..d6f610e 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -61,6 +61,7 @@ function install_dpdk()
 cd dpdk-stable-$1
 fi
 find ./ -type f | xargs sed -i 
's/max-inline-insns-single=100/max-inline-insns-single=400/'
+find ./ -type f | xargs sed -i 's/-Werror/-Werror -Wno-error=inline/'
 echo 'CONFIG_RTE_BUILD_FPIC=y' >>config/common_linuxapp
 sed -ri '/EXECENV_CFLAGS  = -pthread -fPIC/{s/$/\nelse ifeq 
($(CONFIG_RTE_BUILD_FPIC),y)/;s/$/\nEXECENV_CFLAGS  = -pthread -fPIC/}' 
mk/exec-env/linuxapp/rte.vars.mk
 make config CC=gcc T=x86_64-native-linuxapp-gcc
-- 
1.9.1

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


Re: [ovs-dev] [PATCH v4 2/5] netdev-dpdk: Add netdev_dpdk_vhost_txq_flush function.

2017-08-09 Thread Ilya Maximets
Not a full review.
One comment inline.

> Add netdev_dpdk_vhost_txq_flush(), that flushes packets on vHost User
> port queues. Also add netdev_dpdk_vhost_tx_burst() function that
> uses rte_vhost_enqueue_burst() to enqueue burst of packets on vHost User
> ports.
> 
> Signed-off-by: Bhanuprakash Bodireddy 
> Signed-off-by: Antonio Fischetti 
> Co-authored-by: Antonio Fischetti 
> Acked-by: Eelco Chaudron 
> ---
>  lib/netdev-dpdk.c | 112 
> --
>  1 file changed, 108 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index 50d6b29..d3892fe 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -327,12 +327,22 @@ struct dpdk_tx_queue {
>  * pmd threads (see 'concurrent_txq'). */
>  int map;   /* Mapping of configured vhost-user queues
>  * to enabled by guest. */
> -int dpdk_pkt_cnt;  /* Number of buffered packets waiting to
> +union {
> +int dpdk_pkt_cnt;  /* Number of buffered packets waiting to
>be sent on DPDK tx queue. */
> -struct rte_mbuf *dpdk_burst_pkts[INTERIM_QUEUE_BURST_THRESHOLD];
> +int vhost_pkt_cnt; /* Number of buffered packets waiting to
> +  be sent on vhost port. */
> +};
> +
> +union {
> +struct rte_mbuf *dpdk_burst_pkts[INTERIM_QUEUE_BURST_THRESHOLD];
> /* Intermediate queue where packets can
>  * be buffered to amortize the cost of 
> MMIO
>  * writes. */
> +struct dp_packet *vhost_burst_pkts[INTERIM_QUEUE_BURST_THRESHOLD];
> +   /* Intermediate queue where packets can
> +* be buffered for vhost ports. */
> +};
>  };
>  
>  /* dpdk has no way to remove dpdk ring ethernet devices
> @@ -1756,6 +1766,88 @@ netdev_dpdk_vhost_update_tx_counters(struct 
> netdev_stats *stats,
>  }
>  }
>  
> +static int
> +netdev_dpdk_vhost_tx_burst(struct netdev_dpdk *dev, int qid)
> +{
> +struct dpdk_tx_queue *txq = >tx_q[qid];
> +struct rte_mbuf **cur_pkts = (struct rte_mbuf **)txq->vhost_burst_pkts;
> +
> +int tx_vid = netdev_dpdk_get_vid(dev);
> +int tx_qid = qid * VIRTIO_QNUM + VIRTIO_RXQ;
> +uint32_t sent = 0;
> +uint32_t retries = 0;
> +uint32_t sum, total_pkts;
> +
> +total_pkts = sum = txq->vhost_pkt_cnt;
> +do {
> +uint32_t ret;
> +ret = rte_vhost_enqueue_burst(tx_vid, tx_qid, _pkts[sent], sum);
> +if (OVS_UNLIKELY(!ret)) {
> +/* No packets enqueued - do not retry. */
> +break;
> +} else {
> +/* Packet have been sent. */
> +sent += ret;
> +
> +/* 'sum' packet have to be retransmitted. */
> +sum -= ret;
> +}
> +} while (sum && (retries++ < VHOST_ENQ_RETRY_NUM));
> +
> +for (int i = 0; i < total_pkts; i++) {
> +dp_packet_delete(txq->vhost_burst_pkts[i]);
> +}
> +
> +/* Reset pkt count. */
> +txq->vhost_pkt_cnt = 0;
> +
> +/* 'sum' refers to packets dropped. */
> +return sum;
> +}
> +
> +/* Flush the txq if there are any packets available. */
> +static int
> +netdev_dpdk_vhost_txq_flush(struct netdev *netdev, int qid,
> +bool concurrent_txq OVS_UNUSED)
> +{
> +struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
> +struct dpdk_tx_queue *txq;
> +
> +qid = dev->tx_q[qid % netdev->n_txq].map;
> +
> +/* The qid may be disabled in the guest and has been set to
> + * OVS_VHOST_QUEUE_DISABLED.
> + */
> +if (OVS_UNLIKELY(qid < 0)) {
> +return 0;
> +}
> +
> +txq = >tx_q[qid];
> +/* Increment the drop count and free the memory. */
> +if (OVS_UNLIKELY(!is_vhost_running(dev) ||
> + !(dev->flags & NETDEV_UP))) {
> +
> +if (txq->vhost_pkt_cnt) {
> +rte_spinlock_lock(>stats_lock);
> +dev->stats.tx_dropped+= txq->vhost_pkt_cnt;
> +rte_spinlock_unlock(>stats_lock);
> +
> +for (int i = 0; i < txq->vhost_pkt_cnt; i++) {
> +dp_packet_delete(txq->vhost_burst_pkts[i]);

Spinlock (tx_lock) must be held here to avoid queue and mempool breakage.

> +}
> +txq->vhost_pkt_cnt = 0;
> +}
> +}
> +
> +if (OVS_LIKELY(txq->vhost_pkt_cnt)) {
> +rte_spinlock_lock(>tx_q[qid].tx_lock);
> +netdev_dpdk_vhost_tx_burst(dev, qid);
> +rte_spinlock_unlock(>tx_q[qid].tx_lock);
> +}
> +
> +return 0;
> +}
> +
>  static void
>  __netdev_dpdk_vhost_send(struct netdev *netdev, int qid,
>   struct dp_packet **pkts, int cnt)
> @@ -2799,6 +2891,17 @@ vring_state_changed(int vid, uint16_t 

Re: [ovs-dev] [PATCH v4 1/5] netdev: Add netdev_txq_flush function.

2017-08-09 Thread Ilya Maximets
Not a full review.
Comments inline.

> Add netdev_txq_flush(), that flush packets on a queue. This is needed
> to transmit packets on the intermediate queue.
> 
> This commit also implements netdev_dpdk_txq_flush() function. If there
> are any packets waiting in the queue, they are transmitted instantly
> using the rte_eth_tx_burst function. In XPS enabled case, lock is
> taken on the tx queue before flushing the queue.
> 
> Signed-off-by: Bhanuprakash Bodireddy 
> Signed-off-by: Antonio Fischetti 
> Co-authored-by: Antonio Fischetti 
> Signed-off-by: Markus Magnusson 
> Co-authored-by: Markus Magnusson 
> Acked-by: Eelco Chaudron 
> ---
>  lib/netdev-bsd.c  |  1 +
>  lib/netdev-dpdk.c | 52 
> ++-
>  lib/netdev-dummy.c|  1 +
>  lib/netdev-linux.c|  1 +
>  lib/netdev-provider.h |  8 
>  lib/netdev-vport.c|  2 +-
>  lib/netdev.c  |  9 +
>  lib/netdev.h  |  1 +
>  8 files changed, 69 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/netdev-bsd.c b/lib/netdev-bsd.c
> index 8a4cdb3..75483ad 100644
> --- a/lib/netdev-bsd.c
> +++ b/lib/netdev-bsd.c
> @@ -1546,6 +1546,7 @@ netdev_bsd_update_flags(struct netdev *netdev_, enum 
> netdev_flags off,
>  netdev_bsd_rxq_recv, \
>  netdev_bsd_rxq_wait, \
>  netdev_bsd_rxq_drain,\
> +NULL,\
>   \
>  NO_OFFLOAD_API   \
>  }
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index 1d82bca..50d6b29 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -313,6 +313,11 @@ struct dpdk_mp {
>  struct ovs_list list_node OVS_GUARDED_BY(dpdk_mp_mutex);
>  };
>  
> +/* Queue 'INTERIM_QUEUE_BURST_THRESHOLD' packets before transmitting.
> + * Defaults to 'NETDEV_MAX_BURST'(32) packets.
> + */
> +#define INTERIM_QUEUE_BURST_THRESHOLD NETDEV_MAX_BURST
> +
>  /* There should be one 'struct dpdk_tx_queue' created for
>   * each cpu core. */
>  struct dpdk_tx_queue {
> @@ -322,6 +327,12 @@ struct dpdk_tx_queue {
>  * pmd threads (see 'concurrent_txq'). */
>  int map;   /* Mapping of configured vhost-user queues
>  * to enabled by guest. */
> +int dpdk_pkt_cnt;  /* Number of buffered packets waiting to
> +  be sent on DPDK tx queue. */
> +struct rte_mbuf *dpdk_burst_pkts[INTERIM_QUEUE_BURST_THRESHOLD];
> +   /* Intermediate queue where packets can
> +* be buffered to amortize the cost of 
> MMIO
> +* writes. */
>  };
>  
>  /* dpdk has no way to remove dpdk ring ethernet devices
> @@ -1931,6 +1942,32 @@ netdev_dpdk_send__(struct netdev_dpdk *dev, int qid,
>  }
>  }
>  
> +/* Flush tx queues.
> + * This is done periodically to empty the intermediate queue in case of
> + * fewer packets (< INTERIM_QUEUE_BURST_THRESHOLD) buffered in the queue.
> + */
> +static int
> +netdev_dpdk_txq_flush(struct netdev *netdev, int qid , bool concurrent_txq)
> +{
> +struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
> +struct dpdk_tx_queue *txq = >tx_q[qid];
> +
> +if (OVS_LIKELY(txq->dpdk_pkt_cnt)) {
> +if (OVS_UNLIKELY(concurrent_txq)) {
> +qid = qid % dev->up.n_txq;
> +rte_spinlock_lock(>tx_q[qid].tx_lock);
> +}
> +
> +netdev_dpdk_eth_tx_burst(dev, qid, txq->dpdk_burst_pkts,
> + txq->dpdk_pkt_cnt);

The queue used for send and the locked one are different because you're
remapping the qid before taking the spinlock.

I suspect that we're always using right queue numbers in current
implementation of dpif-netdev, but I need to recheck to be sure.
Anyway, logic of this function completely broken. 

> +
> +if (OVS_UNLIKELY(concurrent_txq)) {
> +rte_spinlock_unlock(>tx_q[qid].tx_lock);
> +}
> +}
> +return 0;
> +}
> +
>  static int
>  netdev_dpdk_eth_send(struct netdev *netdev, int qid,
>   struct dp_packet_batch *batch, bool may_steal,
> @@ -3313,7 +3350,7 @@ unlock:
>SET_CONFIG, SET_TX_MULTIQ, SEND,\
>GET_CARRIER, GET_STATS, \
>GET_FEATURES, GET_STATUS,   \
> -  RECONFIGURE, RXQ_RECV)  \
> +  RECONFIGURE, RXQ_RECV, TXQ_FLUSH)   \
>  { \
>  NAME, \
>  true,   /* is_pmd */  \
> @@ -3381,6 +3418,7 @@ unlock:
>  RXQ_RECV, 

Re: [ovs-dev] [PATCH 0/5] dpif-netdev: Cuckoo-Distributor implementation

2017-08-09 Thread Fischetti, Antonio
Any comment on this patchset?

Adding Jan in CC.

In one of the last bi-weekly meeting there was some interest in testing
this patchset in conjunction with the patch to avoid using EMC for
recirculated packets - this is contained inside the patchset
https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/335938.html


Thanks,
-Antonio


> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org]
> On Behalf Of Wang, Yipeng1
> Sent: Tuesday, July 11, 2017 8:59 PM
> To: Darrell Ball ; d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH 0/5] dpif-netdev: Cuckoo-Distributor
> implementation
> 
> Thank you Darrell for the comments.
> 
> To ones who are interested, this patch is mainly for improving the subtable
> lookup process when subtable count is large. We heard about use cases that
> the current sequential search of subtables is not efficient enough.  With 30
> subtables, this patch could achieve more than 2x speedup.  Basically, a hash
> table is used to direct the packets to correct sub-table.
> 
> We also plan a replacement policy mechanism for version 2, our initial results
> Show another 7% improvement on top of current CD for certain use cases.
> 
> Please feel free to comment and share any thought on this patch.
> 
> Thanks
> Yipeng
> 
> > -Original Message-
> > From: Darrell Ball [mailto:db...@vmware.com]
> > Sent: Friday, July 7, 2017 6:37 PM
> > To: Wang, Yipeng1 ; d...@openvswitch.org
> > Subject: Re: [ovs-dev] [PATCH 0/5] dpif-netdev: Cuckoo-Distributor
> > implementation
> >
> > I just noticed this patch set has not had much discussion since the RFC
> > version.
> > It would be nice if the discussion can be revived.
> >
> > Thanks Darrell
> >
> >
> > On 6/13/17, 4:09 PM, "ovs-dev-boun...@openvswitch.org on behalf of
> > yipeng1.w...@intel.com"  > yipeng1.w...@intel.com> wrote:
> >
> > From: Yipeng Wang 
> >
> > The Datapath Classifier uses tuple space search for flow classification.
> > The rules are arranged into a set of tuples/subtables (each with a
> > distinct mask).  Each subtable is implemented as a hash table and lookup
> > is done with flow keys formed by selecting the bits from the packet
> header
> > based on each subtable's mask. Tuple space search will sequentially
> search
> > each subtable until a match is found. With a large number of subtables, 
> > a
> > sequential search of the subtables could consume a lot of CPU cycles. In
> > a testbench with a uniform traffic pattern equally distributed across 20
> > subtables, we measured that up to 65% of total execution time is
> > attributed
> > to the megaflow cache lookup.
> >
> > This patch presents the idea of the two-layer hierarchical lookup, where
> a
> > low overhead first level of indirection is accessed first, we call this
> > level cuckoo distributor (CD). If a flow key has been inserted in the
> flow
> > table the first level will indicate with high probability that which
> > subtable to look into. A lookup is performed on the second level (the
> > target subtable) to retrieve the result. If the key doesn’t have a 
> > match,
> > then we revert back to the sequential search of subtables. The patch is
> > partially inspired by earlier concepts proposed in "simTable"[1] and
> > "Cuckoo Filter"[2], and DPDK's Cuckoo Hash implementation.
> >
> > This patch can improve the already existing Subtable Ranking when 
> > traffic
> > data has high entropy. Subtable Ranking helps minimize the number of
> > traversed subtables when most of the traffic hit the same subtable.
> > However, in the case of high entropy traffic such as traffic coming from
> > a physical port, multiple subtables could be hit with a similar
> frequency.
> > In this case the average subtable lookups per hit would be much greater
> > than 1. In addition, CD can adaptively turn off when it finds the 
> > traffic
> > mostly hit one subtable. Thus, CD will not be an overhead when Subtable
> > Ranking works well.
> >
> > Scheme:
> >
> >  ---
> > |  CD   |
> >  ---
> >\
> > \
> >  -  - -
> > |sub  ||sub  |...|sub  |
> > |table||table|   |table|
> >  -  - -
> >
> > Evaluation:
> >
> > We create set of rules with various src IP. We feed traffic containing
> various
> > numbers of flows with various src IP and dst IP. All the flows hit
> 10/20/30
> > rules creating 10/20/30 subtables.
> >
> > The table below shows the preliminary continuous testing results (full
> line
> > speed test) we collected with a uni-directional phy-to-phy setup. The
> > machine we tested on is a Xeon E5 server running with 2.2GHz cores. OvS
> > runs with 1 PMD. We use Spirent as the 

Re: [ovs-dev] [PATCH] ovn-northd: Add native active-standby HA.

2017-08-09 Thread Miguel Angel Ajo Pelayo
Nice idea, I have btw some comments/thoughts/questions regarding this:

1) Does OVSDB have any heartbeat protocol? (to detect that one northd has
died even during inactive periods).

 Otherwise we can document the need to tweak the tcp_keepalive settings
of the system to have some sensible settings that will make TCP detect the
connection failure in a reasonable amount of time.

2) We need to consider that in some cases the master ovsdb server and the
northd process will be colocated and therefore fall together. I guess that
in that case the lock is replicated to the slave ovsdb server, we need to
make sure that the lock will be dropped once the old slave(backup) becomes
master.


Best regards,


On Wed, Aug 2, 2017 at 8:05 PM, Russell Bryant  wrote:

> On Tue, Aug 1, 2017 at 9:21 PM, Numan Siddique 
> wrote:
> >
> >
> > On Wed, Aug 2, 2017 at 1:18 AM, Russell Bryant  wrote:
> >>
> >> On Tue, Aug 1, 2017 at 3:26 PM, Han Zhou  wrote:
> >> >
> >> >
> >> > On Tue, Aug 1, 2017 at 9:19 AM, Russell Bryant 
> wrote:
> >> >>
> >> >> Add native support for active-standby HA in ovn-northd by having each
> >> >> instance attempt to acquire an OVSDB lock.  Only the instance of
> >> >> ovn-northd that currently holds the lock will make active changes to
> >> >> the OVN databases.
> >> >>
> >> >> Signed-off-by: Russell Bryant 
> >> >> ---
> >> >>  NEWS|  1 +
> >> >>  ovn/northd/ovn-northd.8.xml |  9 +
> >> >>  ovn/northd/ovn-northd.c | 40
> >> >> +++-
> >> >>  3 files changed, 41 insertions(+), 9 deletions(-)
> >> >>
> >> >> diff --git a/NEWS b/NEWS
> >> >> index facea0228..f3cdd2443 100644
> >> >> --- a/NEWS
> >> >> +++ b/NEWS
> >> >> @@ -49,6 +49,7 @@ Post-v2.7.0
> >> >> one chassis is specified, OVN will manage high availability
> for
> >> >> that
> >> >> gateway.
> >> >>   * Add support for ACL logging.
> >> >> + * ovn-northd now has native support for active-standby high
> >> >> availability.
> >> >> - Tracing with ofproto/trace now traces through recirculation.
> >> >> - OVSDB:
> >> >>   * New support for role-based access control (see
> >> >> ovsdb-server(1)).
> >> >> diff --git a/ovn/northd/ovn-northd.8.xml
> b/ovn/northd/ovn-northd.8.xml
> >> >> index 1527e8a60..0d85ec0d2 100644
> >> >> --- a/ovn/northd/ovn-northd.8.xml
> >> >> +++ b/ovn/northd/ovn-northd.8.xml
> >> >> @@ -72,6 +72,15 @@
> >> >>
> >> >>  
> >> >>
> >> >> +Active-Standby for High Availability
> >> >> +
> >> >> +  You may run ovn-northd more than once in an OVN
> >> >> deployment.
> >> >> +  OVN will automatically ensure that only one of them is active
> at
> >> >> a
> >> >> time.
> >> >> +  If multiple instances of ovn-northd are running
> and
> >> >> the
> >> >> +  active ovn-northd fails, one of the hot standby
> >> >> instances
> >> >> +  of ovn-northd will automatically take over.
> >> >> +
> >> >> +
> >> >>  Logical Flow Table Structure
> >> >>
> >> >>  
> >> >> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> >> >> index 10e0c7ce0..3d2be4267 100644
> >> >> --- a/ovn/northd/ovn-northd.c
> >> >> +++ b/ovn/northd/ovn-northd.c
> >> >> @@ -6531,6 +6531,12 @@ main(int argc, char *argv[])
> >> >>  ovsdb_idl_add_column(ovnsb_idl_loop.idl,
> >> >> _chassis_col_nb_cfg);
> >> >>  ovsdb_idl_add_column(ovnsb_idl_loop.idl,
> _chassis_col_name);
> >> >>
> >> >> +/* Ensure that only a single ovn-northd is active in the
> >> >> deployment
> >> >> by
> >> >> + * acquiring a lock called "ovn_northd" on the southbound
> database
> >> >> + * and then only performing DB transactions if the lock is held.
> >> >> */
> >> >> +ovsdb_idl_set_lock(ovnsb_idl_loop.idl, "ovn_northd");
> >> >> +bool had_lock = false;
> >> >> +
> >> >>  /* Main loop. */
> >> >>  exiting = false;
> >> >>  while (!exiting) {
> >> >> @@ -6541,15 +6547,29 @@ main(int argc, char *argv[])
> >> >>  .ovnsb_txn = ovsdb_idl_loop_run(_idl_loop),
> >> >>  };
> >> >>
> >> >> -struct chassis_index chassis_index;
> >> >> -chassis_index_init(_index, ctx.ovnsb_idl);
> >> >> +if (!had_lock && ovsdb_idl_has_lock(ovnsb_idl_loop.idl)) {
> >> >> +VLOG_INFO("ovn-northd lock acquired. "
> >> >> +  "This ovn-northd instance is now active.");
> >> >> +had_lock = true;
> >> >> +} else if (had_lock &&
> >> >> !ovsdb_idl_has_lock(ovnsb_idl_loop.idl)) {
> >> >> +VLOG_INFO("ovn-northd lock lost. "
> >> >> +  "This ovn-northd instance is now on
> standby.");
> >> >
> >> > Should it try lock again, if we want it to be standby? Otherwise, this
> >> > instance won't have a chance to be active any more.
> >>
> >> Good question ... I was assuming this scenario was due to a 

Re: [ovs-dev] [PATCH v4 2/5] netdev-dpdk: Add netdev_dpdk_vhost_txq_flush function.

2017-08-09 Thread Ilya Maximets
One more comment inline.

On 09.08.2017 11:06, Ilya Maximets wrote:
> Not a full review.
> One comment inline.
> 
>> Add netdev_dpdk_vhost_txq_flush(), that flushes packets on vHost User
>> port queues. Also add netdev_dpdk_vhost_tx_burst() function that
>> uses rte_vhost_enqueue_burst() to enqueue burst of packets on vHost User
>> ports.
>>
>> Signed-off-by: Bhanuprakash Bodireddy 
>> Signed-off-by: Antonio Fischetti 
>> Co-authored-by: Antonio Fischetti 
>> Acked-by: Eelco Chaudron 
>> ---
>>  lib/netdev-dpdk.c | 112 
>> --
>>  1 file changed, 108 insertions(+), 4 deletions(-)
>>
>> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
>> index 50d6b29..d3892fe 100644
>> --- a/lib/netdev-dpdk.c
>> +++ b/lib/netdev-dpdk.c
>> @@ -327,12 +327,22 @@ struct dpdk_tx_queue {
>>  * pmd threads (see 'concurrent_txq'). */
>>  int map;   /* Mapping of configured vhost-user 
>> queues
>>  * to enabled by guest. */
>> -int dpdk_pkt_cnt;  /* Number of buffered packets waiting to
>> +union {
>> +int dpdk_pkt_cnt;  /* Number of buffered packets waiting to
>>be sent on DPDK tx queue. */
>> -struct rte_mbuf *dpdk_burst_pkts[INTERIM_QUEUE_BURST_THRESHOLD];
>> +int vhost_pkt_cnt; /* Number of buffered packets waiting to
>> +  be sent on vhost port. */
>> +};
>> +
>> +union {
>> +struct rte_mbuf *dpdk_burst_pkts[INTERIM_QUEUE_BURST_THRESHOLD];
>> /* Intermediate queue where packets can
>>  * be buffered to amortize the cost of 
>> MMIO
>>  * writes. */
>> +struct dp_packet *vhost_burst_pkts[INTERIM_QUEUE_BURST_THRESHOLD];
>> +   /* Intermediate queue where packets can
>> +* be buffered for vhost ports. */
>> +};
>>  };
>>  
>>  /* dpdk has no way to remove dpdk ring ethernet devices
>> @@ -1756,6 +1766,88 @@ netdev_dpdk_vhost_update_tx_counters(struct 
>> netdev_stats *stats,
>>  }
>>  }
>>  
>> +static int
>> +netdev_dpdk_vhost_tx_burst(struct netdev_dpdk *dev, int qid)
>> +{
>> +struct dpdk_tx_queue *txq = >tx_q[qid];
>> +struct rte_mbuf **cur_pkts = (struct rte_mbuf **)txq->vhost_burst_pkts;
>> +
>> +int tx_vid = netdev_dpdk_get_vid(dev);
>> +int tx_qid = qid * VIRTIO_QNUM + VIRTIO_RXQ;
>> +uint32_t sent = 0;
>> +uint32_t retries = 0;
>> +uint32_t sum, total_pkts;
>> +
>> +total_pkts = sum = txq->vhost_pkt_cnt;
>> +do {
>> +uint32_t ret;
>> +ret = rte_vhost_enqueue_burst(tx_vid, tx_qid, _pkts[sent], sum);
>> +if (OVS_UNLIKELY(!ret)) {
>> +/* No packets enqueued - do not retry. */
>> +break;
>> +} else {
>> +/* Packet have been sent. */
>> +sent += ret;
>> +
>> +/* 'sum' packet have to be retransmitted. */
>> +sum -= ret;
>> +}
>> +} while (sum && (retries++ < VHOST_ENQ_RETRY_NUM));
>> +
>> +for (int i = 0; i < total_pkts; i++) {
>> +dp_packet_delete(txq->vhost_burst_pkts[i]);
>> +}
>> +
>> +/* Reset pkt count. */
>> +txq->vhost_pkt_cnt = 0;
>> +
>> +/* 'sum' refers to packets dropped. */
>> +return sum;
>> +}
>> +
>> +/* Flush the txq if there are any packets available. */
>> +static int
>> +netdev_dpdk_vhost_txq_flush(struct netdev *netdev, int qid,
>> +bool concurrent_txq OVS_UNUSED)
>> +{
>> +struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
>> +struct dpdk_tx_queue *txq;
>> +
>> +qid = dev->tx_q[qid % netdev->n_txq].map;
>> +
>> +/* The qid may be disabled in the guest and has been set to
>> + * OVS_VHOST_QUEUE_DISABLED.
>> + */
>> +if (OVS_UNLIKELY(qid < 0)) {
>> +return 0;
>> +}
>> +
>> +txq = >tx_q[qid];
>> +/* Increment the drop count and free the memory. */
>> +if (OVS_UNLIKELY(!is_vhost_running(dev) ||
>> + !(dev->flags & NETDEV_UP))) {
>> +
>> +if (txq->vhost_pkt_cnt) {
>> +rte_spinlock_lock(>stats_lock);
>> +dev->stats.tx_dropped+= txq->vhost_pkt_cnt;
>> +rte_spinlock_unlock(>stats_lock);
>> +
>> +for (int i = 0; i < txq->vhost_pkt_cnt; i++) {
>> +dp_packet_delete(txq->vhost_burst_pkts[i]);
> 
> Spinlock (tx_lock) must be held here to avoid queue and mempool breakage.
> 
>> +}
>> +txq->vhost_pkt_cnt = 0;
>> +}
>> +}
>> +
>> +if (OVS_LIKELY(txq->vhost_pkt_cnt)) {
>> +rte_spinlock_lock(>tx_q[qid].tx_lock);
>> +netdev_dpdk_vhost_tx_burst(dev, qid);
>> +rte_spinlock_unlock(>tx_q[qid].tx_lock);
>> +}
>> +
>> +return 

Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support

2017-08-09 Thread Yang, Yi Y
Hi,  Jan

I have worked out a patch, will send it quickly for Ben. In addition, I also 
will send out a patch to change encap_nsh _nsh to push_nsh and pop_nsh. 
Per comments from all the people, we all agreed to do so :-)

diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index bc6c94b..4936c12 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -793,7 +793,7 @@ struct ovs_action_push_eth {
struct ovs_key_ethernet addresses;
 };

-#define OVS_ENCAP_NSH_MAX_MD_LEN 16
+#define OVS_ENCAP_NSH_MAX_MD_LEN 248
 /*
  * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
  * @flags: NSH header flags.
@@ -809,7 +809,7 @@ struct ovs_action_encap_nsh {
 uint8_t mdlen;
 uint8_t np;
 __be32 path_hdr;
-uint8_t metadata[OVS_ENCAP_NSH_MAX_MD_LEN];
+uint8_t metadata[];
 };

 /**
diff --git a/lib/odp-util.c b/lib/odp-util.c
index ef8b39d..91452f5 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -1785,7 +1785,8 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 {
 int n = 0;
 int ret = 0;
-struct ovs_action_encap_nsh encap_nsh;
+struct ovs_action_encap_nsh *encap_nsh =
+xmalloc(sizeof *encap_nsh + OVS_ENCAP_NSH_MAX_MD_LEN);
 uint32_t spi;
 uint8_t si;
 uint32_t cd;
@@ -1796,11 +1797,11 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 }

 /* The default is NSH_M_TYPE1 */
-encap_nsh.flags = 0;
-encap_nsh.mdtype = NSH_M_TYPE1;
-encap_nsh.mdlen = NSH_M_TYPE1_MDLEN;
-encap_nsh.path_hdr = htonl(255);
-memset(encap_nsh.metadata, 0, NSH_M_TYPE1_MDLEN);
+encap_nsh->flags = 0;
+encap_nsh->mdtype = NSH_M_TYPE1;
+encap_nsh->mdlen = NSH_M_TYPE1_MDLEN;
+encap_nsh->path_hdr = htonl(255);
+memset(encap_nsh->metadata, 0, encap_nsh->mdlen);

 for (;;) {
 n += strspn(s + n, delimiters);
@@ -1808,17 +1809,17 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 break;
 }

-if (ovs_scan_len(s, , "flags=%"SCNi8, _nsh.flags)) {
+if (ovs_scan_len(s, , "flags=%"SCNi8, _nsh->flags)) {
 continue;
 }
-if (ovs_scan_len(s, , "mdtype=%"SCNi8, _nsh.mdtype)) {
-switch (encap_nsh.mdtype) {
+if (ovs_scan_len(s, , "mdtype=%"SCNi8, _nsh->mdtype)) {
+switch (encap_nsh->mdtype) {
 case NSH_M_TYPE1:
 /* This is the default format. */;
 break;
 case NSH_M_TYPE2:
 /* Length will be updated later. */
-encap_nsh.mdlen = 0;
+encap_nsh->mdlen = 0;
 break;
 default:
 ret = -EINVAL;
@@ -1826,24 +1827,24 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 }
 continue;
 }
-if (ovs_scan_len(s, , "np=%"SCNi8, _nsh.np)) {
+if (ovs_scan_len(s, , "np=%"SCNi8, _nsh->np)) {
 continue;
 }
 if (ovs_scan_len(s, , "spi=0x%"SCNx32, )) {
-encap_nsh.path_hdr =
+encap_nsh->path_hdr =
 htonl(((spi << NSH_SPI_SHIFT) & NSH_SPI_MASK) |
-(ntohl(encap_nsh.path_hdr) & ~NSH_SPI_MASK));
+(ntohl(encap_nsh->path_hdr) & ~NSH_SPI_MASK));
 continue;
 }
 if (ovs_scan_len(s, , "si=%"SCNi8, )) {
-encap_nsh.path_hdr =
+encap_nsh->path_hdr =
 htonl((si << NSH_SI_SHIFT) |
-(ntohl(encap_nsh.path_hdr) & ~NSH_SI_MASK));
+(ntohl(encap_nsh->path_hdr) & ~NSH_SI_MASK));
 continue;
 }
-if (encap_nsh.mdtype == NSH_M_TYPE1) {
+if (encap_nsh->mdtype == NSH_M_TYPE1) {
 struct nsh_md1_ctx *md1 =
-ALIGNED_CAST(struct nsh_md1_ctx *, encap_nsh.metadata);
+ALIGNED_CAST(struct nsh_md1_ctx *, encap_nsh->metadata);
 if (ovs_scan_len(s, , "c1=0x%"SCNx32, )) {
 put_16aligned_be32(>c[0], htonl(cd));
 continue;
@@ -1861,30 +1862,34 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 continue;
 }
 }
-else if (encap_nsh.mdtype == NSH_M_TYPE2) {
+else if (encap_nsh->mdtype == NSH_M_TYPE2) {
 struct ofpbuf b;
 char buf[512];
 size_t mdlen;
 if (ovs_scan_len(s, , "md2=0x%511[0-9a-fA-F]", buf)) {
-ofpbuf_use_stub(, encap_nsh.metadata,
+ofpbuf_use_stub(, encap_nsh->metadata,
 OVS_ENCAP_NSH_MAX_MD_LEN);
 ofpbuf_put_hex(, buf, );
-encap_nsh.mdlen = mdlen;
+encap_nsh->mdlen = mdlen;
 ofpbuf_uninit();
 

Re: [ovs-dev] [PATCHv2] ovn: Add support for ACL logging.

2017-08-09 Thread Miguel Angel Ajo Pelayo
Nice addition :D

On Sat, Jul 29, 2017 at 2:01 AM, Justin Pettit  wrote:

>
> > On Jul 28, 2017, at 4:57 PM, Ben Pfaff  wrote:
> >
> > On Fri, Jul 28, 2017 at 03:48:38PM -0700, Justin Pettit wrote:
> >> Signed-off-by: Justin Pettit 
> >> Acked-by: Han Zhou 
> >> ---
> >> v1->v2: Incorporate Ben and Han's feedback.
> >>Improve output of "ovn-nbctl acl-list".
> >
> > Thank you!
> >
> > I'm appending a few final suggestions.  The only important one is the
> > one that moves the free() call, which I believe fixes a double-free on
> > the error path: the old name is freed but not set to NULL, which means
> > that ovnact_log_free() eventually frees it again.
>
> Good catches.  I added your changes and pushed to master.
>
> Thanks!
>
> --Justin
>
>
> ___
> 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] Why my AT_CHECK() can't work?

2017-08-09 Thread Sam
Hi all,

I'm using autotest to test ovs, and I write a new *.at file using only one
AT_CHECK sentence like this:

AT_CHECK([ovs-appctl dpdk/bond-show dpdkb2], [0], [stdout])
> AT_CHECK([[sed '/ACTIVE/p' stdout | head -4]], [0], [[LACP actor_state
> ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING]])


but this *.at file failed, log is:

789. netdev-dpdk.at:23: testing netdev-dpdk - dpdk/bond-show ...
> ./netdev-dpdk.at:27: ovs-appctl dpdk/bond-show dpdkb2
> stdout:
>  dpdkb2 
> bond_mode: 4
> slave 0:
> active
> mac address ec:f4:bb:e1:1a:40
> Link Up - speed 1 Mbps - full-duplex
> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>  rx pkts=268449, bytes=16502449, mcasts=0, drop=0, errs=0, nombufs=0
>  tx pkts=261, bytes=32020, errs=0
> slave 1:
> active
> mac address ec:f4:bb:e1:1a:42
> Link Up - speed 1 Mbps - full-duplex
> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>  rx pkts=296190, bytes=17934647, mcasts=0, drop=0, errs=0, nombufs=0
>  tx pkts=254, bytes=31496, errs=0
> ./netdev-dpdk.at:28: sed '/ACTIVE/p' stdout | head -4
> --- -   2017-08-09 16:59:18.802810195 +0800
> +++ /home/gangyewei-3/mvs/mvs/tests/testsuite.dir/at-groups/789/stdout
>  2017-08-09 16:59:18.801176471 +0800
> @@ -1,4 +1,5 @@
> -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> + dpdkb2 
> +bond_mode: 4
> +
> +slave 0:
> +
> 789. netdev-dpdk.at:23: 789. netdev-dpdk - dpdk/bond-show (
> netdev-dpdk.at:23): FAILED (netdev-dpdk.at:28)


1. I don't know what "+" "-" means, and why there are "+" and "-"?
2. I run `ovs-appctl dpdk/bond-show dpdkb2 | sed -n '/ACTIVE/p' | head -4`
in command line, result is:

> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING

That's exactly what I matched in AT_CHECK, why it fails?

Autotest is really hard to use...
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] Why my AT_CHECK() can't work?

2017-08-09 Thread Sam
Then I change commd into `awk '/ACTIVE/' stdout | head -4`, it failed
again, log is :

./netdev-dpdk.at:28: awk '/ACTIVE/' stdout | head -4
> --- -   2017-08-09 17:41:24.809066088 +0800
> +++ /home/gangyewei-3/mvs/mvs/tests/testsuite.dir/at-groups/789/stdout
>  2017-08-09 17:41:24.807150522 +0800
> @@ -1,5 +1,5 @@
> -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> +LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> + partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> +LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> + partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> 789. netdev-dpdk.at:23: 789. netdev-dpdk - dpdk/bond-show (
> netdev-dpdk.at:23): FAILED (netdev-dpdk.at:28)


I don't know where is the difference

2017-08-09 17:15 GMT+08:00 Sam :

> Hi all,
>
> I'm using autotest to test ovs, and I write a new *.at file using only one
> AT_CHECK sentence like this:
>
> AT_CHECK([ovs-appctl dpdk/bond-show dpdkb2], [0], [stdout])
>> AT_CHECK([[sed '/ACTIVE/p' stdout | head -4]], [0], [[LACP actor_state
>> ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING]])
>
>
> but this *.at file failed, log is:
>
> 789. netdev-dpdk.at:23: testing netdev-dpdk - dpdk/bond-show ...
>> ./netdev-dpdk.at:27: ovs-appctl dpdk/bond-show dpdkb2
>> stdout:
>>  dpdkb2 
>> bond_mode: 4
>> slave 0:
>> active
>> mac address ec:f4:bb:e1:1a:40
>> Link Up - speed 1 Mbps - full-duplex
>> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>>  rx pkts=268449, bytes=16502449, mcasts=0, drop=0, errs=0, nombufs=0
>>  tx pkts=261, bytes=32020, errs=0
>> slave 1:
>> active
>> mac address ec:f4:bb:e1:1a:42
>> Link Up - speed 1 Mbps - full-duplex
>> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>>  rx pkts=296190, bytes=17934647, mcasts=0, drop=0, errs=0, nombufs=0
>>  tx pkts=254, bytes=31496, errs=0
>> ./netdev-dpdk.at:28: sed '/ACTIVE/p' stdout | head -4
>> --- -   2017-08-09 16:59:18.802810195 +0800
>> +++ /home/gangyewei-3/mvs/mvs/tests/testsuite.dir/at-groups/789/stdout
>>  2017-08-09 16:59:18.801176471 +0800
>> @@ -1,4 +1,5 @@
>> -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>> - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>> -LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>> - partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>> + dpdkb2 
>> +bond_mode: 4
>> +
>> +slave 0:
>> +
>> 789. netdev-dpdk.at:23: 789. netdev-dpdk - dpdk/bond-show (
>> netdev-dpdk.at:23): FAILED (netdev-dpdk.at:28)
>
>
> 1. I don't know what "+" "-" means, and why there are "+" and "-"?
> 2. I run `ovs-appctl dpdk/bond-show dpdkb2 | sed -n '/ACTIVE/p' | head
> -4`, result is:
>
>> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>
> That's exactly what I matched in AT_CHECK, why it fails?
>
> Autotest is really hard to use...
>
>
2017-08-09 17:23 GMT+08:00 Sam :

> Hi all,
>
> I'm using autotest to test ovs, and I write a new *.at file using only one
> AT_CHECK sentence like this:
>
> AT_CHECK([ovs-appctl dpdk/bond-show dpdkb2], [0], [stdout])
>> AT_CHECK([[sed '/ACTIVE/p' stdout | head -4]], [0], [[LACP actor_state
>> ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING]])
>
>
> but this *.at file failed, log is:
>
> 789. netdev-dpdk.at:23: testing netdev-dpdk - dpdk/bond-show ...
>> ./netdev-dpdk.at:27: ovs-appctl dpdk/bond-show dpdkb2
>> stdout:
>>  dpdkb2 
>> bond_mode: 4
>> slave 0:
>> active
>> mac address ec:f4:bb:e1:1a:40
>> Link Up - speed 1 Mbps - full-duplex
>> LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>>  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
>>  rx pkts=268449, bytes=16502449, mcasts=0, drop=0, errs=0, nombufs=0
>>  tx pkts=261, bytes=32020, errs=0
>> slave 1:
>> active
>> mac address ec:f4:bb:e1:1a:42
>> Link Up - speed 1 Mbps - full-duplex
>> LACP actor_state 

[ovs-dev] [PATCH] nsh: enable struct ovs_action_encap_nsh to support variable length

2017-08-09 Thread Yi Yang
In order to adapt to MD type 1 and MD type 2 at the same
time and avoid breaking Linux kernel uAPI later, we change
struct ovs_action_encap_nsh to the below format.

struct ovs_action_encap_nsh {
uint8_t flags;
uint8_t mdtype;
uint8_t mdlen;
uint8_t np;
__be32 path_hdr;
uint8_t metadata[];
};

struct ovs_action_encap_nsh will be allocated dynamically when
it is used.

The following patch will change encap_nsh and decap_nsh into
push_nsh and pop_nsh, respectively, Linux kernel guys prefer
push_* and pop_*.

Signed-off-by: Yi Yang 
---
 datapath/linux/compat/include/linux/openvswitch.h |   4 +-
 lib/odp-util.c| 101 +-
 tests/nsh.at  |  10 +--
 3 files changed, 65 insertions(+), 50 deletions(-)

diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index bc6c94b..4936c12 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -793,7 +793,7 @@ struct ovs_action_push_eth {
struct ovs_key_ethernet addresses;
 };
 
-#define OVS_ENCAP_NSH_MAX_MD_LEN 16
+#define OVS_ENCAP_NSH_MAX_MD_LEN 248
 /*
  * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
  * @flags: NSH header flags.
@@ -809,7 +809,7 @@ struct ovs_action_encap_nsh {
 uint8_t mdlen;
 uint8_t np;
 __be32 path_hdr;
-uint8_t metadata[OVS_ENCAP_NSH_MAX_MD_LEN];
+uint8_t metadata[];
 };
 
 /**
diff --git a/lib/odp-util.c b/lib/odp-util.c
index ef8b39d..91452f5 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -1785,7 +1785,8 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 {
 int n = 0;
 int ret = 0;
-struct ovs_action_encap_nsh encap_nsh;
+struct ovs_action_encap_nsh *encap_nsh =
+xmalloc(sizeof *encap_nsh + OVS_ENCAP_NSH_MAX_MD_LEN);
 uint32_t spi;
 uint8_t si;
 uint32_t cd;
@@ -1796,11 +1797,11 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 }
 
 /* The default is NSH_M_TYPE1 */
-encap_nsh.flags = 0;
-encap_nsh.mdtype = NSH_M_TYPE1;
-encap_nsh.mdlen = NSH_M_TYPE1_MDLEN;
-encap_nsh.path_hdr = htonl(255);
-memset(encap_nsh.metadata, 0, NSH_M_TYPE1_MDLEN);
+encap_nsh->flags = 0;
+encap_nsh->mdtype = NSH_M_TYPE1;
+encap_nsh->mdlen = NSH_M_TYPE1_MDLEN;
+encap_nsh->path_hdr = htonl(255);
+memset(encap_nsh->metadata, 0, encap_nsh->mdlen);
 
 for (;;) {
 n += strspn(s + n, delimiters);
@@ -1808,17 +1809,17 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 break;
 }
 
-if (ovs_scan_len(s, , "flags=%"SCNi8, _nsh.flags)) {
+if (ovs_scan_len(s, , "flags=%"SCNi8, _nsh->flags)) {
 continue;
 }
-if (ovs_scan_len(s, , "mdtype=%"SCNi8, _nsh.mdtype)) {
-switch (encap_nsh.mdtype) {
+if (ovs_scan_len(s, , "mdtype=%"SCNi8, _nsh->mdtype)) {
+switch (encap_nsh->mdtype) {
 case NSH_M_TYPE1:
 /* This is the default format. */;
 break;
 case NSH_M_TYPE2:
 /* Length will be updated later. */
-encap_nsh.mdlen = 0;
+encap_nsh->mdlen = 0;
 break;
 default:
 ret = -EINVAL;
@@ -1826,24 +1827,24 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 }
 continue;
 }
-if (ovs_scan_len(s, , "np=%"SCNi8, _nsh.np)) {
+if (ovs_scan_len(s, , "np=%"SCNi8, _nsh->np)) {
 continue;
 }
 if (ovs_scan_len(s, , "spi=0x%"SCNx32, )) {
-encap_nsh.path_hdr =
+encap_nsh->path_hdr =
 htonl(((spi << NSH_SPI_SHIFT) & NSH_SPI_MASK) |
-(ntohl(encap_nsh.path_hdr) & ~NSH_SPI_MASK));
+(ntohl(encap_nsh->path_hdr) & ~NSH_SPI_MASK));
 continue;
 }
 if (ovs_scan_len(s, , "si=%"SCNi8, )) {
-encap_nsh.path_hdr =
+encap_nsh->path_hdr =
 htonl((si << NSH_SI_SHIFT) |
-(ntohl(encap_nsh.path_hdr) & ~NSH_SI_MASK));
+(ntohl(encap_nsh->path_hdr) & ~NSH_SI_MASK));
 continue;
 }
-if (encap_nsh.mdtype == NSH_M_TYPE1) {
+if (encap_nsh->mdtype == NSH_M_TYPE1) {
 struct nsh_md1_ctx *md1 =
-ALIGNED_CAST(struct nsh_md1_ctx *, encap_nsh.metadata);
+ALIGNED_CAST(struct nsh_md1_ctx *, encap_nsh->metadata);
 if (ovs_scan_len(s, , "c1=0x%"SCNx32, )) {
 put_16aligned_be32(>c[0], htonl(cd));
 continue;
@@ -1861,30 +1862,34 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 

[ovs-dev] [PATCH v1 2/2] nsh: rename encap_nsh and decap_nsh as push_nsh and pop_nsh

2017-08-09 Thread Yi Yang
Per kernel data path naming convention, we need to rename
encap_nsh and decap_nsh as push_nsh and pop_nsh, respectively.

This change will make sure our data path actions follow the
same convention in both userspace and kernel data path.

The variables, structs, function names are also changed to
apply new names.

Signed-off-by: Yi Yang 
---
 datapath/linux/compat/include/linux/openvswitch.h |  14 +-
 lib/dpif-netdev.c |   4 +-
 lib/dpif.c|   4 +-
 lib/odp-execute.c |  14 +-
 lib/odp-util.c| 162 +++---
 lib/packets.c |  20 +--
 lib/packets.h |   6 +-
 ofproto/ofproto-dpif-ipfix.c  |   4 +-
 ofproto/ofproto-dpif-sflow.c  |   4 +-
 ofproto/ofproto-dpif-xlate.c  |  16 +--
 tests/nsh.at  |  22 +--
 11 files changed, 135 insertions(+), 135 deletions(-)

diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index 4936c12..49f5221 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -793,9 +793,9 @@ struct ovs_action_push_eth {
struct ovs_key_ethernet addresses;
 };
 
-#define OVS_ENCAP_NSH_MAX_MD_LEN 248
+#define OVS_PUSH_NSH_MAX_MD_LEN 248
 /*
- * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
+ * struct ovs_action_push_nsh - %OVS_ACTION_ATTR_PUSH_NSH
  * @flags: NSH header flags.
  * @mdtype: NSH metadata type.
  * @mdlen: Length of NSH metadata in bytes.
@@ -803,7 +803,7 @@ struct ovs_action_push_eth {
  * @path_hdr: NSH service path id and service index.
  * @metadata: NSH metadata for MD type 1 or 2
  */
-struct ovs_action_encap_nsh {
+struct ovs_action_push_nsh {
 uint8_t flags;
 uint8_t mdtype;
 uint8_t mdlen;
@@ -887,8 +887,8 @@ enum ovs_nat_attr {
  * @OVS_ACTION_ATTR_PUSH_ETH: Push a new outermost Ethernet header onto the
  * packet.
  * @OVS_ACTION_ATTR_POP_ETH: Pop the outermost Ethernet header off the packet.
- * @OVS_ACTION_ATTR_ENCAP_NSH: encap NSH action to push NSH header.
- * @OVS_ACTION_ATTR_DECAP_NSH: decap NSH action to remove NSH header.
+ * @OVS_ACTION_ATTR_PUSH_NSH: push NSH header to the packet.
+ * @OVS_ACTION_ATTR_POP_NSH: pop the outermost NSH header off the packet.
  *
  * Only a single header can be set with a single %OVS_ACTION_ATTR_SET.  Not all
  * fields within a header are modifiable, e.g. the IPv4 protocol and fragment
@@ -930,8 +930,8 @@ enum ovs_action_attr {
OVS_ACTION_ATTR_TUNNEL_POP,/* u32 port number. */
OVS_ACTION_ATTR_CLONE, /* Nested OVS_CLONE_ATTR_*.  */
OVS_ACTION_ATTR_METER, /* u32 meter number. */
-   OVS_ACTION_ATTR_ENCAP_NSH,/* struct ovs_action_encap_nsh. */
-   OVS_ACTION_ATTR_DECAP_NSH,/* No argument. */
+   OVS_ACTION_ATTR_PUSH_NSH,  /* struct ovs_action_push_nsh. */
+   OVS_ACTION_ATTR_POP_NSH,   /* No argument. */
 #endif
__OVS_ACTION_ATTR_MAX,/* Nothing past this will be accepted
   * from userspace. */
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index e2cd931..527fa0e 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -5407,8 +5407,8 @@ dp_execute_cb(void *aux_, struct dp_packet_batch 
*packets_,
 case OVS_ACTION_ATTR_PUSH_ETH:
 case OVS_ACTION_ATTR_POP_ETH:
 case OVS_ACTION_ATTR_CLONE:
-case OVS_ACTION_ATTR_ENCAP_NSH:
-case OVS_ACTION_ATTR_DECAP_NSH:
+case OVS_ACTION_ATTR_PUSH_NSH:
+case OVS_ACTION_ATTR_POP_NSH:
 case __OVS_ACTION_ATTR_MAX:
 OVS_NOT_REACHED();
 }
diff --git a/lib/dpif.c b/lib/dpif.c
index e71f6a3..5ab4c85 100644
--- a/lib/dpif.c
+++ b/lib/dpif.c
@@ -1255,8 +1255,8 @@ dpif_execute_helper_cb(void *aux_, struct dp_packet_batch 
*packets_,
 case OVS_ACTION_ATTR_PUSH_ETH:
 case OVS_ACTION_ATTR_POP_ETH:
 case OVS_ACTION_ATTR_CLONE:
-case OVS_ACTION_ATTR_ENCAP_NSH:
-case OVS_ACTION_ATTR_DECAP_NSH:
+case OVS_ACTION_ATTR_PUSH_NSH:
+case OVS_ACTION_ATTR_POP_NSH:
 case OVS_ACTION_ATTR_UNSPEC:
 case __OVS_ACTION_ATTR_MAX:
 OVS_NOT_REACHED();
diff --git a/lib/odp-execute.c b/lib/odp-execute.c
index 5f4d23a..8a61028 100644
--- a/lib/odp-execute.c
+++ b/lib/odp-execute.c
@@ -652,8 +652,8 @@ requires_datapath_assistance(const struct nlattr *a)
 case OVS_ACTION_ATTR_PUSH_ETH:
 case OVS_ACTION_ATTR_POP_ETH:
 case OVS_ACTION_ATTR_CLONE:
-case OVS_ACTION_ATTR_ENCAP_NSH:
-case OVS_ACTION_ATTR_DECAP_NSH:
+case OVS_ACTION_ATTR_PUSH_NSH:
+case OVS_ACTION_ATTR_POP_NSH:
 return false;
 
 case OVS_ACTION_ATTR_UNSPEC:
@@ -818,18 +818,18 @@ odp_execute_actions(void *dp, struct dp_packet_batch 
*batch, 

[ovs-dev] [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to support variable length

2017-08-09 Thread Yi Yang
In order to adapt to MD type 1 and MD type 2 at the same
time and avoid breaking Linux kernel uAPI later, we change
struct ovs_action_encap_nsh to the below format.

struct ovs_action_encap_nsh {
uint8_t flags;
uint8_t mdtype;
uint8_t mdlen;
uint8_t np;
__be32 path_hdr;
uint8_t metadata[];
};

struct ovs_action_encap_nsh will be allocated dynamically when
it is used.

The following patch will change encap_nsh and decap_nsh into
push_nsh and pop_nsh, respectively, Linux kernel guys prefer
push_* and pop_*.

Signed-off-by: Yi Yang 
---
 datapath/linux/compat/include/linux/openvswitch.h |   4 +-
 lib/odp-util.c| 101 +-
 tests/nsh.at  |  10 +--
 3 files changed, 65 insertions(+), 50 deletions(-)

diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index bc6c94b..4936c12 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -793,7 +793,7 @@ struct ovs_action_push_eth {
struct ovs_key_ethernet addresses;
 };
 
-#define OVS_ENCAP_NSH_MAX_MD_LEN 16
+#define OVS_ENCAP_NSH_MAX_MD_LEN 248
 /*
  * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
  * @flags: NSH header flags.
@@ -809,7 +809,7 @@ struct ovs_action_encap_nsh {
 uint8_t mdlen;
 uint8_t np;
 __be32 path_hdr;
-uint8_t metadata[OVS_ENCAP_NSH_MAX_MD_LEN];
+uint8_t metadata[];
 };
 
 /**
diff --git a/lib/odp-util.c b/lib/odp-util.c
index ef8b39d..91452f5 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -1785,7 +1785,8 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 {
 int n = 0;
 int ret = 0;
-struct ovs_action_encap_nsh encap_nsh;
+struct ovs_action_encap_nsh *encap_nsh =
+xmalloc(sizeof *encap_nsh + OVS_ENCAP_NSH_MAX_MD_LEN);
 uint32_t spi;
 uint8_t si;
 uint32_t cd;
@@ -1796,11 +1797,11 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 }
 
 /* The default is NSH_M_TYPE1 */
-encap_nsh.flags = 0;
-encap_nsh.mdtype = NSH_M_TYPE1;
-encap_nsh.mdlen = NSH_M_TYPE1_MDLEN;
-encap_nsh.path_hdr = htonl(255);
-memset(encap_nsh.metadata, 0, NSH_M_TYPE1_MDLEN);
+encap_nsh->flags = 0;
+encap_nsh->mdtype = NSH_M_TYPE1;
+encap_nsh->mdlen = NSH_M_TYPE1_MDLEN;
+encap_nsh->path_hdr = htonl(255);
+memset(encap_nsh->metadata, 0, encap_nsh->mdlen);
 
 for (;;) {
 n += strspn(s + n, delimiters);
@@ -1808,17 +1809,17 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 break;
 }
 
-if (ovs_scan_len(s, , "flags=%"SCNi8, _nsh.flags)) {
+if (ovs_scan_len(s, , "flags=%"SCNi8, _nsh->flags)) {
 continue;
 }
-if (ovs_scan_len(s, , "mdtype=%"SCNi8, _nsh.mdtype)) {
-switch (encap_nsh.mdtype) {
+if (ovs_scan_len(s, , "mdtype=%"SCNi8, _nsh->mdtype)) {
+switch (encap_nsh->mdtype) {
 case NSH_M_TYPE1:
 /* This is the default format. */;
 break;
 case NSH_M_TYPE2:
 /* Length will be updated later. */
-encap_nsh.mdlen = 0;
+encap_nsh->mdlen = 0;
 break;
 default:
 ret = -EINVAL;
@@ -1826,24 +1827,24 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 }
 continue;
 }
-if (ovs_scan_len(s, , "np=%"SCNi8, _nsh.np)) {
+if (ovs_scan_len(s, , "np=%"SCNi8, _nsh->np)) {
 continue;
 }
 if (ovs_scan_len(s, , "spi=0x%"SCNx32, )) {
-encap_nsh.path_hdr =
+encap_nsh->path_hdr =
 htonl(((spi << NSH_SPI_SHIFT) & NSH_SPI_MASK) |
-(ntohl(encap_nsh.path_hdr) & ~NSH_SPI_MASK));
+(ntohl(encap_nsh->path_hdr) & ~NSH_SPI_MASK));
 continue;
 }
 if (ovs_scan_len(s, , "si=%"SCNi8, )) {
-encap_nsh.path_hdr =
+encap_nsh->path_hdr =
 htonl((si << NSH_SI_SHIFT) |
-(ntohl(encap_nsh.path_hdr) & ~NSH_SI_MASK));
+(ntohl(encap_nsh->path_hdr) & ~NSH_SI_MASK));
 continue;
 }
-if (encap_nsh.mdtype == NSH_M_TYPE1) {
+if (encap_nsh->mdtype == NSH_M_TYPE1) {
 struct nsh_md1_ctx *md1 =
-ALIGNED_CAST(struct nsh_md1_ctx *, encap_nsh.metadata);
+ALIGNED_CAST(struct nsh_md1_ctx *, encap_nsh->metadata);
 if (ovs_scan_len(s, , "c1=0x%"SCNx32, )) {
 put_16aligned_be32(>c[0], htonl(cd));
 continue;
@@ -1861,30 +1862,34 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 

[ovs-dev] [PATCH v1 0/2] nsh: change data path action names and struct to adapt to kernel requirements

2017-08-09 Thread Yi Yang
This patch series is to adapt to kernel data path requirments, all the people
have made an agreement, we need to use variable struct ovs_action_encap_nsh
and push_nsh & pop_nsh.

Yi Yang (2):
  nsh: enable struct ovs_action_encap_nsh to support variable length
  nsh: rename encap_nsh and decap_nsh as push_nsh and pop_nsh

 datapath/linux/compat/include/linux/openvswitch.h |  16 +--
 lib/dpif-netdev.c |   4 +-
 lib/dpif.c|   4 +-
 lib/odp-execute.c |  14 +-
 lib/odp-util.c| 163 --
 lib/packets.c |  20 +--
 lib/packets.h |   6 +-
 ofproto/ofproto-dpif-ipfix.c  |   4 +-
 ofproto/ofproto-dpif-sflow.c  |   4 +-
 ofproto/ofproto-dpif-xlate.c  |  16 +--
 tests/nsh.at  |  28 ++--
 11 files changed, 147 insertions(+), 132 deletions(-)

-- 
2.1.0

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


Re: [ovs-dev] [PATCH] nsh: enable struct ovs_action_encap_nsh to support variable length

2017-08-09 Thread Yang, Yi Y
Please ignore this one and use this series 
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/337128.html which 
includes this one.

-Original Message-
From: Yang, Yi Y 
Sent: Wednesday, August 9, 2017 5:56 PM
To: d...@openvswitch.org
Cc: b...@ovn.org; Yang, Yi Y 
Subject: [PATCH] nsh: enable struct ovs_action_encap_nsh to support variable 
length

In order to adapt to MD type 1 and MD type 2 at the same time and avoid 
breaking Linux kernel uAPI later, we change struct ovs_action_encap_nsh to the 
below format.

struct ovs_action_encap_nsh {
uint8_t flags;
uint8_t mdtype;
uint8_t mdlen;
uint8_t np;
__be32 path_hdr;
uint8_t metadata[];
};

struct ovs_action_encap_nsh will be allocated dynamically when it is used.

The following patch will change encap_nsh and decap_nsh into push_nsh and 
pop_nsh, respectively, Linux kernel guys prefer
push_* and pop_*.

Signed-off-by: Yi Yang 
---
 datapath/linux/compat/include/linux/openvswitch.h |   4 +-
 lib/odp-util.c| 101 +-
 tests/nsh.at  |  10 +--
 3 files changed, 65 insertions(+), 50 deletions(-)

diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index bc6c94b..4936c12 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -793,7 +793,7 @@ struct ovs_action_push_eth {
struct ovs_key_ethernet addresses;
 };
 
-#define OVS_ENCAP_NSH_MAX_MD_LEN 16
+#define OVS_ENCAP_NSH_MAX_MD_LEN 248
 /*
  * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
  * @flags: NSH header flags.
@@ -809,7 +809,7 @@ struct ovs_action_encap_nsh {
 uint8_t mdlen;
 uint8_t np;
 __be32 path_hdr;
-uint8_t metadata[OVS_ENCAP_NSH_MAX_MD_LEN];
+uint8_t metadata[];
 };
 
 /**
diff --git a/lib/odp-util.c b/lib/odp-util.c index ef8b39d..91452f5 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -1785,7 +1785,8 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)  {
 int n = 0;
 int ret = 0;
-struct ovs_action_encap_nsh encap_nsh;
+struct ovs_action_encap_nsh *encap_nsh =
+xmalloc(sizeof *encap_nsh + OVS_ENCAP_NSH_MAX_MD_LEN);
 uint32_t spi;
 uint8_t si;
 uint32_t cd;
@@ -1796,11 +1797,11 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 }
 
 /* The default is NSH_M_TYPE1 */
-encap_nsh.flags = 0;
-encap_nsh.mdtype = NSH_M_TYPE1;
-encap_nsh.mdlen = NSH_M_TYPE1_MDLEN;
-encap_nsh.path_hdr = htonl(255);
-memset(encap_nsh.metadata, 0, NSH_M_TYPE1_MDLEN);
+encap_nsh->flags = 0;
+encap_nsh->mdtype = NSH_M_TYPE1;
+encap_nsh->mdlen = NSH_M_TYPE1_MDLEN;
+encap_nsh->path_hdr = htonl(255);
+memset(encap_nsh->metadata, 0, encap_nsh->mdlen);
 
 for (;;) {
 n += strspn(s + n, delimiters); @@ -1808,17 +1809,17 @@ 
parse_odp_encap_nsh_action(const char *s, struct ofpbuf *actions)
 break;
 }
 
-if (ovs_scan_len(s, , "flags=%"SCNi8, _nsh.flags)) {
+if (ovs_scan_len(s, , "flags=%"SCNi8, _nsh->flags)) {
 continue;
 }
-if (ovs_scan_len(s, , "mdtype=%"SCNi8, _nsh.mdtype)) {
-switch (encap_nsh.mdtype) {
+if (ovs_scan_len(s, , "mdtype=%"SCNi8, _nsh->mdtype)) {
+switch (encap_nsh->mdtype) {
 case NSH_M_TYPE1:
 /* This is the default format. */;
 break;
 case NSH_M_TYPE2:
 /* Length will be updated later. */
-encap_nsh.mdlen = 0;
+encap_nsh->mdlen = 0;
 break;
 default:
 ret = -EINVAL;
@@ -1826,24 +1827,24 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf 
*actions)
 }
 continue;
 }
-if (ovs_scan_len(s, , "np=%"SCNi8, _nsh.np)) {
+if (ovs_scan_len(s, , "np=%"SCNi8, _nsh->np)) {
 continue;
 }
 if (ovs_scan_len(s, , "spi=0x%"SCNx32, )) {
-encap_nsh.path_hdr =
+encap_nsh->path_hdr =
 htonl(((spi << NSH_SPI_SHIFT) & NSH_SPI_MASK) |
-(ntohl(encap_nsh.path_hdr) & ~NSH_SPI_MASK));
+(ntohl(encap_nsh->path_hdr) & 
+ ~NSH_SPI_MASK));
 continue;
 }
 if (ovs_scan_len(s, , "si=%"SCNi8, )) {
-encap_nsh.path_hdr =
+encap_nsh->path_hdr =
 htonl((si << NSH_SI_SHIFT) |
-(ntohl(encap_nsh.path_hdr) & ~NSH_SI_MASK));
+(ntohl(encap_nsh->path_hdr) & 
+ ~NSH_SI_MASK));
 continue;
 }
-if (encap_nsh.mdtype == NSH_M_TYPE1) {
+if (encap_nsh->mdtype == NSH_M_TYPE1) {
 struct nsh_md1_ctx *md1 =
-  

[ovs-dev] ovsdb-server replication: Possible to exclude syncing specific column of a table??

2017-08-09 Thread Arunkumar Rg
Hi All,

I need a clarification on ovsdb-server replication's
set-sync-exclude-tables.

*Is there a way, by which we can say exclude syncing specific column of a
table??*

The use case I'm looking at is:

   1. The replication is configured for DB "hardware_vtep".
   2. I'm trying to use the "ovsdb-server/set-sync-exclude-tables" unixctl
   command for table "hardware_vtep:Manager" on the backup ovsdb-server.
   3. After this the backup ovsdb-server gets replica(notification) from
   the active's db except for 'Manager' table.
   4. At this poiint, while processing the notification for 'Global' table,
   I see the below error:
   5. "Aug  9 12:26:38 Pollux daemon.err ovsdb-server:
   ovs|00070|ovsdb_error|ERR|unexpected ovsdb error: referential integrity
   violation: Table Global column managers row
   4121ba6c-a729-45b1-8f69-806b32584d04 references nonexistent row
   5dbedec1-8221-435f-89b3-503867d0e987 in t""
   6. I think this error could be avoided if we can say exclude syncing
   'Manager' column in 'Global' table also.


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


Re: [ovs-dev] [PATCH v4 2/5] netdev-dpdk: Add netdev_dpdk_vhost_txq_flush function.

2017-08-09 Thread Ilya Maximets
On 09.08.2017 13:03, Ilya Maximets wrote:
> One more comment inline.
> 
> On 09.08.2017 11:06, Ilya Maximets wrote:
>> Not a full review.
>> One comment inline.
>>
>>> Add netdev_dpdk_vhost_txq_flush(), that flushes packets on vHost User
>>> port queues. Also add netdev_dpdk_vhost_tx_burst() function that
>>> uses rte_vhost_enqueue_burst() to enqueue burst of packets on vHost User
>>> ports.
>>>
>>> Signed-off-by: Bhanuprakash Bodireddy 
>>> Signed-off-by: Antonio Fischetti 
>>> Co-authored-by: Antonio Fischetti 
>>> Acked-by: Eelco Chaudron 
>>> ---
>>>  lib/netdev-dpdk.c | 112 
>>> --
>>>  1 file changed, 108 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
>>> index 50d6b29..d3892fe 100644
>>> --- a/lib/netdev-dpdk.c
>>> +++ b/lib/netdev-dpdk.c
>>> @@ -327,12 +327,22 @@ struct dpdk_tx_queue {
>>>  * pmd threads (see 'concurrent_txq'). 
>>> */
>>>  int map;   /* Mapping of configured vhost-user 
>>> queues
>>>  * to enabled by guest. */
>>> -int dpdk_pkt_cnt;  /* Number of buffered packets waiting to
>>> +union {
>>> +int dpdk_pkt_cnt;  /* Number of buffered packets waiting to
>>>be sent on DPDK tx queue. */
>>> -struct rte_mbuf *dpdk_burst_pkts[INTERIM_QUEUE_BURST_THRESHOLD];
>>> +int vhost_pkt_cnt; /* Number of buffered packets waiting to
>>> +  be sent on vhost port. */
>>> +};
>>> +
>>> +union {
>>> +struct rte_mbuf *dpdk_burst_pkts[INTERIM_QUEUE_BURST_THRESHOLD];
>>> /* Intermediate queue where packets can
>>>  * be buffered to amortize the cost of 
>>> MMIO
>>>  * writes. */
>>> +struct dp_packet *vhost_burst_pkts[INTERIM_QUEUE_BURST_THRESHOLD];
>>> +   /* Intermediate queue where packets can
>>> +* be buffered for vhost ports. */
>>> +};
>>>  };
>>>  
>>>  /* dpdk has no way to remove dpdk ring ethernet devices
>>> @@ -1756,6 +1766,88 @@ netdev_dpdk_vhost_update_tx_counters(struct 
>>> netdev_stats *stats,
>>>  }
>>>  }
>>>  
>>> +static int
>>> +netdev_dpdk_vhost_tx_burst(struct netdev_dpdk *dev, int qid)
>>> +{
>>> +struct dpdk_tx_queue *txq = >tx_q[qid];
>>> +struct rte_mbuf **cur_pkts = (struct rte_mbuf **)txq->vhost_burst_pkts;
>>> +
>>> +int tx_vid = netdev_dpdk_get_vid(dev);
>>> +int tx_qid = qid * VIRTIO_QNUM + VIRTIO_RXQ;
>>> +uint32_t sent = 0;
>>> +uint32_t retries = 0;
>>> +uint32_t sum, total_pkts;
>>> +
>>> +total_pkts = sum = txq->vhost_pkt_cnt;
>>> +do {
>>> +uint32_t ret;
>>> +ret = rte_vhost_enqueue_burst(tx_vid, tx_qid, _pkts[sent], 
>>> sum);
>>> +if (OVS_UNLIKELY(!ret)) {
>>> +/* No packets enqueued - do not retry. */
>>> +break;
>>> +} else {
>>> +/* Packet have been sent. */
>>> +sent += ret;
>>> +
>>> +/* 'sum' packet have to be retransmitted. */
>>> +sum -= ret;
>>> +}
>>> +} while (sum && (retries++ < VHOST_ENQ_RETRY_NUM));
>>> +
>>> +for (int i = 0; i < total_pkts; i++) {
>>> +dp_packet_delete(txq->vhost_burst_pkts[i]);
>>> +}
>>> +
>>> +/* Reset pkt count. */
>>> +txq->vhost_pkt_cnt = 0;
>>> +
>>> +/* 'sum' refers to packets dropped. */
>>> +return sum;
>>> +}
>>> +
>>> +/* Flush the txq if there are any packets available. */
>>> +static int
>>> +netdev_dpdk_vhost_txq_flush(struct netdev *netdev, int qid,
>>> +bool concurrent_txq OVS_UNUSED)
>>> +{
>>> +struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
>>> +struct dpdk_tx_queue *txq;
>>> +
>>> +qid = dev->tx_q[qid % netdev->n_txq].map;
>>> +
>>> +/* The qid may be disabled in the guest and has been set to
>>> + * OVS_VHOST_QUEUE_DISABLED.
>>> + */
>>> +if (OVS_UNLIKELY(qid < 0)) {
>>> +return 0;
>>> +}
>>> +
>>> +txq = >tx_q[qid];
>>> +/* Increment the drop count and free the memory. */
>>> +if (OVS_UNLIKELY(!is_vhost_running(dev) ||
>>> + !(dev->flags & NETDEV_UP))) {
>>> +
>>> +if (txq->vhost_pkt_cnt) {
>>> +rte_spinlock_lock(>stats_lock);
>>> +dev->stats.tx_dropped+= txq->vhost_pkt_cnt;
>>> +rte_spinlock_unlock(>stats_lock);
>>> +
>>> +for (int i = 0; i < txq->vhost_pkt_cnt; i++) {
>>> +dp_packet_delete(txq->vhost_burst_pkts[i]);
>>
>> Spinlock (tx_lock) must be held here to avoid queue and mempool breakage.
>>
>>> +}
>>> +txq->vhost_pkt_cnt = 0;
>>> +}
>>> +}
>>> +
>>> +if (OVS_LIKELY(txq->vhost_pkt_cnt)) {

[ovs-dev] Spring Roll Pastry

2017-08-09 Thread Bonesca
    [ View in browser ]( http://r.newsletter.bonescamail.nl/nru6rm8uoatrf.html 
)   
 
 
 
TYJ SPRING ROLL PASTRY SINGAPORE
 
Code - Description
8842  - 215 mm 40 leaves 20 x 500 gr
8843  - 250 mm 30 leaves 30 x 500 gr
 
1 Box € 1,75
10 Box € 1,65
Palet € 1,55 per pack!    

 
This email was sent to d...@openvswitch.org
You received this email because you are registered with Bonesca Import en 
Export BV
 
[ Unsubscribe here ]( http://r.newsletter.bonescamail.nl/nru6rm8uoatrg.html )  

Sent by
[  ]( http://r.newsletter.bonescamail.nl/click/2n3cr2gz1aoatrd.html )     
© 2017 Bonesca Import en Export BV  

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


Re: [ovs-dev] [PATCH v4 1/5] netdev: Add netdev_txq_flush function.

2017-08-09 Thread Bodireddy, Bhanuprakash
Hi Ilya,
>>
>> +/* Flush tx queues.
>> + * This is done periodically to empty the intermediate queue in case
>> +of
>> + * fewer packets (< INTERIM_QUEUE_BURST_THRESHOLD) buffered in the
>queue.
>> + */
>> +static int
>> +netdev_dpdk_txq_flush(struct netdev *netdev, int qid , bool
>> +concurrent_txq) {
>> +struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
>> +struct dpdk_tx_queue *txq = >tx_q[qid];
>> +
>> +if (OVS_LIKELY(txq->dpdk_pkt_cnt)) {
>> +if (OVS_UNLIKELY(concurrent_txq)) {
>> +qid = qid % dev->up.n_txq;
>> +rte_spinlock_lock(>tx_q[qid].tx_lock);
>> +}
>> +
>> +netdev_dpdk_eth_tx_burst(dev, qid, txq->dpdk_burst_pkts,
>> + txq->dpdk_pkt_cnt);
>
>The queue used for send and the locked one are different because you're
>remapping the qid before taking the spinlock.

>I suspect that we're always using right queue numbers in current
>implementation of dpif-netdev, but I need to recheck to be sure.

I believe the case you are referring here is the XPS case ('dynamic_txqs' true).
When we have to flush the packets we retrieve the qid from the 
'cached_tx_port->last_used_qid'
 that was initialized earlier by 'dpif_netdev_xps_get_tx_qid()'. The logic of 
remapping the qid and 
acquiring the spin lock in the above function is no different from current 
logic in master. Can you 
elaborate the specific case where this would break the functionality?

Please note that  in 'dpif_netdev_xps_get_tx_qid'  the qid can change and so we 
did flush the queue.  

- Bhanuprakash. 

>Anyway, logic of this function completely broken.
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v4 2/5] netdev-dpdk: Add netdev_dpdk_vhost_txq_flush function.

2017-08-09 Thread Bodireddy, Bhanuprakash
>>
>> +static int
>> +netdev_dpdk_vhost_tx_burst(struct netdev_dpdk *dev, int qid) {
>> +struct dpdk_tx_queue *txq = >tx_q[qid];
>> +struct rte_mbuf **cur_pkts = (struct rte_mbuf
>> +**)txq->vhost_burst_pkts;
>> +
>> +int tx_vid = netdev_dpdk_get_vid(dev);
>> +int tx_qid = qid * VIRTIO_QNUM + VIRTIO_RXQ;
>> +uint32_t sent = 0;
>> +uint32_t retries = 0;
>> +uint32_t sum, total_pkts;
>> +
>> +total_pkts = sum = txq->vhost_pkt_cnt;
>> +do {
>> +uint32_t ret;
>> +ret = rte_vhost_enqueue_burst(tx_vid, tx_qid, _pkts[sent],
>sum);
>> +if (OVS_UNLIKELY(!ret)) {
>> +/* No packets enqueued - do not retry. */
>> +break;
>> +} else {
>> +/* Packet have been sent. */
>> +sent += ret;
>> +
>> +/* 'sum' packet have to be retransmitted. */
>> +sum -= ret;
>> +}
>> +} while (sum && (retries++ < VHOST_ENQ_RETRY_NUM));
>> +
>> +for (int i = 0; i < total_pkts; i++) {
>> +dp_packet_delete(txq->vhost_burst_pkts[i]);
>> +}
>> +
>> +/* Reset pkt count. */
>> +txq->vhost_pkt_cnt = 0;
>> +
>> +/* 'sum' refers to packets dropped. */
>> +return sum;
>> +}
>> +
>> +/* Flush the txq if there are any packets available. */ static int
>> +netdev_dpdk_vhost_txq_flush(struct netdev *netdev, int qid,
>> +bool concurrent_txq OVS_UNUSED) {
>> +struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
>> +struct dpdk_tx_queue *txq;
>> +
>> +qid = dev->tx_q[qid % netdev->n_txq].map;
>> +
>> +/* The qid may be disabled in the guest and has been set to
>> + * OVS_VHOST_QUEUE_DISABLED.
>> + */
>> +if (OVS_UNLIKELY(qid < 0)) {
>> +return 0;
>> +}
>> +
>> +txq = >tx_q[qid];
>> +/* Increment the drop count and free the memory. */
>> +if (OVS_UNLIKELY(!is_vhost_running(dev) ||
>> + !(dev->flags & NETDEV_UP))) {
>> +
>> +if (txq->vhost_pkt_cnt) {
>> +rte_spinlock_lock(>stats_lock);
>> +dev->stats.tx_dropped+= txq->vhost_pkt_cnt;
>> +rte_spinlock_unlock(>stats_lock);
>> +
>> +for (int i = 0; i < txq->vhost_pkt_cnt; i++) {
>> +dp_packet_delete(txq->vhost_burst_pkts[i]);
>
>Spinlock (tx_lock) must be held here to avoid queue and mempool breakage.

I think you are right. tx_lock might be acquired for freeing the packets.

---
rte_spinlock_lock(>tx_q[qid].tx_lock);
for (int i = 0; i < txq->vhost_pkt_cnt; i++) {
 dp_packet_delete(txq->vhost_burst_pkts[i]);
}
rte_spinlock_unlock(>tx_q[qid].tx_lock);

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


Re: [ovs-dev] [PATCH] tunnel: ToS and TTL inheritance for MPLS tunneled traffic

2017-08-09 Thread Balazs Nemeth
Hi Ben,

As Miklos is on vacation, let me answer your questions.
The 'latest_nw_tos' variable is storing always the updated value of 'nw_tos'. 
It is not always the same as 'flow->nw_tos'. E.g. in xlate_sample_action(), 
'flow' pointer is declared just before calling tnl_port_send(). In case of MPLS 
traffic, '>xin->flow' doesn't have the correct ToS value (it is 
invalidated at that moment), while updated 'latest_nw_tos' is coming from 'ctx' 
argument.

BR,
Balazs

-Original Message-
From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] 
On Behalf Of Ben Pfaff
Sent: 03 August 2017 20:16
To: Miklós Pelyva 
Cc: 'ovs-dev@openvswitch.org' 
Subject: Re: [ovs-dev] [PATCH] tunnel: ToS and TTL inheritance for MPLS 
tunneled traffic

On Fri, Jul 21, 2017 at 01:08:34PM +, Miklós Pelyva wrote:
> When a new outermost MPLS label is added to 'flow' the 'flow''s
> Ethernet type is changed to 'mpls_eth_type'. After the new label is
> set, the 'flow''s MPLS stack is updated, and the L3/4 fields are
> cleared to mark them invalid. This results in loosing the values of
> the 'nw_tos' and the 'nw_ttl' fields from the struct 'flow'.
> 
> Hence, it is impossible to use the ToS and TTL 'inherit' feature in
> case of MPLS tunneled traffic, because currently the values to be
> inherited are coming from the cleared (invalidated) variables of
> struct 'flow'.
> 
> To support inheriting the ToS field to the outer tunnel header even
> in the presence of an MPLS shim header, this patch introduces a new
> variable in the context structure, called 'latest_nw_tos', which is
> used for storing the up-to-date 'nw_tos' value during the flow
> translation, and is referred in the 'tnl_port_send()' function.
> 
> Besides, for every MPLS packet the MPLS TTL field is copied to the
> TTL field of the outer tunnel header, if inheritance is configured.
> 
> Two new unit tests are created for checking the ToS and TTL
> inheritance for IP, and non-IP packets sent over MPLS over IP
> tunnels. The ECN inheritance is not applied in that case, because
> the related RFC 5129 does not describe an individual way, just
> options for ECN in MPLS.
> 
> Signed-off-by: Miklos Pelyva 
> Signed-off-by: Jan Scheurich 
> Co-authored-by: Jan Scheurich 

Thanks for working on improving OVS support for MPLS.  It's definitely
an OVS weak spot and we all appreciate the help.

Can you help me better understand the relationship between flow->nw_tos
and latest_nw_tos?  It looks to me like latest_nw_tos is very literally
copied from flow->nw_tos whenever the latter changes.  So, when do they
differ?  If they are always the same, then there's no need to have both.

Thanks,

Ben.
___
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 v4 1/5] netdev: Add netdev_txq_flush function.

2017-08-09 Thread Ilya Maximets
On 09.08.2017 15:29, Bodireddy, Bhanuprakash wrote:
> Hi Ilya,
>>>
>>> +/* Flush tx queues.
>>> + * This is done periodically to empty the intermediate queue in case
>>> +of
>>> + * fewer packets (< INTERIM_QUEUE_BURST_THRESHOLD) buffered in the
>> queue.
>>> + */
>>> +static int
>>> +netdev_dpdk_txq_flush(struct netdev *netdev, int qid , bool
>>> +concurrent_txq) {
>>> +struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
>>> +struct dpdk_tx_queue *txq = >tx_q[qid];
>>> +
>>> +if (OVS_LIKELY(txq->dpdk_pkt_cnt)) {
>>> +if (OVS_UNLIKELY(concurrent_txq)) {
>>> +qid = qid % dev->up.n_txq;
>>> +rte_spinlock_lock(>tx_q[qid].tx_lock);
>>> +}
>>> +
>>> +netdev_dpdk_eth_tx_burst(dev, qid, txq->dpdk_burst_pkts,
>>> + txq->dpdk_pkt_cnt);
>>
>> The queue used for send and the locked one are different because you're
>> remapping the qid before taking the spinlock.
> 
>> I suspect that we're always using right queue numbers in current
>> implementation of dpif-netdev, but I need to recheck to be sure.
> 
> I believe the case you are referring here is the XPS case ('dynamic_txqs' 
> true).
> When we have to flush the packets we retrieve the qid from the 
> 'cached_tx_port->last_used_qid'
>  that was initialized earlier by 'dpif_netdev_xps_get_tx_qid()'. The logic of 
> remapping the qid and 
> acquiring the spin lock in the above function is no different from current 
> logic in master. Can you 
> elaborate the specific case where this would break the functionality?

Maybe my initial words are not fully correct, but below example shows what I 
tried to say.

1. dpif-netdev calls netdev_dpdk_txq_flush() with qid == 10;
2. txq = >tx_q[10];  // Remember that 'txq' points to queue #10
3. if (txq->dpdk_pkt_cnt) ? true // Is there packets to send to queue #10?
4. qid = 10 % dev->up.n_txq; // Lets assume that dev->up.n_txq == 7
   ---> qid = 10 % 7 = 3
5. rte_spinlock_lock(>tx_q[3].tx_lock); // Locking queue #3
6. netdev_dpdk_eth_tx_burst(dev, 3, txq->dpdk_burst_pkts, ..);
   --> sending to queue #3 packets enqueued for queue #10 ('txq' still points 
to queue #10)
   At this point queue #10 is not locked, so 'txq->dpdk_burst_pkts' is not 
protected
   from modifications, which could lead to wrong mempool refilling or driver 
crash.
   Also, you're trying to send not right packets to the queue.

   I mentioned that it looks like above scenario is impossible right now and
   qid will always be the same after truncating, but the logic is wrong anyway.

> 
> Please note that  in 'dpif_netdev_xps_get_tx_qid'  the qid can change and so 
> we did flush the queue.  
> 
> - Bhanuprakash. 
> 
>> Anyway, logic of this function completely broken.
>>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v4 2/5] netdev-dpdk: Add netdev_dpdk_vhost_txq_flush function.

2017-08-09 Thread Bodireddy, Bhanuprakash
>enable)
  if (enable) {
  dev->tx_q[qid].map = qid;
>>
>> Here flushing required too because we're possibly enabling previously
>remapped queue.
>>
  } else {
 +/* If the queue is disabled in the guest, the 
 corresponding qid
 + * map shall be set to OVS_VHOST_QUEUE_DISABLED(-2).
 + *
 + * The packets that were queued in 'qid' could be 
 potentially
 + * stuck and needs to be dropped.
 + *
 + * XXX: The queues may be already disabled in the guest so
 + * flush function in this case only helps in updating 
 stats
 + * and freeing memory.
 + */
 +netdev_dpdk_vhost_txq_flush(>up, qid, 0);
  dev->tx_q[qid].map = OVS_VHOST_QUEUE_DISABLED;
  }
  netdev_dpdk_remap_txqs(dev);
>>
>> 'netdev_dpdk_remap_txqs()', actually, is able to change mapping for
>> all the disabled in guest queues. So, we need to flush all of them
>> while remapping somewhere inside the function.
>> One other thing is that there is a race window between flush and
>> mapping update where another process able to enqueue more packets in
>> just flushed queue. The order of operations should be changed, or both
>> of them should be done under the same tx_lock. I think, it's required
>> to make tx_q[].map field atomic to fix the race condition, because
>> send function takes the 'map' and then locks the corresponding queue.
>> It wasn't an issue before, because packets in case of race was just
>> dropped on attempt to send to disabled queue, but with this patch
>> applied they will be enqueued to the intermediate queue and stuck there.
>
>Making 'map' atomic will not help. To solve the race we should make 'reading
>of map + enqueue' an atomic operation by some spinlock.
>Like this:
>
>vhost_send:
>
>qid = qid % netdev->n_txq;
>rte_spinlock_lock(>tx_q[qid].tx_lock);
>
>mapped_qid = dev->tx_q[qid].map;
>
>if (qid != mapped_qid) {
>rte_spinlock_lock(>tx_q[mapped_qid].tx_lock);
>}
>
>tx_enqueue(mapped_qid, pkts, cnt);
>
>if (qid != mapped_qid) {
>rte_spinlock_unlock(>tx_q[mapped_qid].tx_lock);
>}
>
>rte_spinlock_unlock(>tx_q[qid].tx_lock);
>
>
>txq remapping inside 'netdev_dpdk_remap_txqs()' or
>'vring_state_changed()':
>
>qid - queue we need to remap.
>new_qid - queue we need to remap to.
>
>rte_spinlock_lock(>tx_q[qid].tx_lock);
>
>mapped_qid = dev->tx_q[qid].map;
>if (qid != mapped_qid) {
>rte_spinlock_lock(>tx_q[mapped_qid].tx_lock);
>}
>
>tx_flush(mapped_qid)
>
>if (qid != mapped_qid) {
>rte_spinlock_unlock(>tx_q[mapped_qid].tx_lock);
>}
>
>dev->tx_q[qid].map = new_qid;
>
>rte_spinlock_unlock(>tx_q[qid].tx_lock);
>
>
>Above schema should work without races, but looks kind of ugly and requires
>taking of additional spinlock on each send.
>
>P.S. Sorry for talking with myself. Just want to share my thoughts.

Hi Ilya,

Thanks for reviewing the patches and providing inputs.
I went through your comments for this patch(2/5) and agree with the suggestions.
Meanwhile  while go through the changes above and get back to you.

Bhanuprakash. 


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


Re: [ovs-dev] [PATCH v4 2/5] netdev-dpdk: Add netdev_dpdk_vhost_txq_flush function.

2017-08-09 Thread Ilya Maximets
On 09.08.2017 15:35, Bodireddy, Bhanuprakash wrote:
>>>
>>> +static int
>>> +netdev_dpdk_vhost_tx_burst(struct netdev_dpdk *dev, int qid) {
>>> +struct dpdk_tx_queue *txq = >tx_q[qid];
>>> +struct rte_mbuf **cur_pkts = (struct rte_mbuf
>>> +**)txq->vhost_burst_pkts;
>>> +
>>> +int tx_vid = netdev_dpdk_get_vid(dev);
>>> +int tx_qid = qid * VIRTIO_QNUM + VIRTIO_RXQ;
>>> +uint32_t sent = 0;
>>> +uint32_t retries = 0;
>>> +uint32_t sum, total_pkts;
>>> +
>>> +total_pkts = sum = txq->vhost_pkt_cnt;
>>> +do {
>>> +uint32_t ret;
>>> +ret = rte_vhost_enqueue_burst(tx_vid, tx_qid, _pkts[sent],
>> sum);
>>> +if (OVS_UNLIKELY(!ret)) {
>>> +/* No packets enqueued - do not retry. */
>>> +break;
>>> +} else {
>>> +/* Packet have been sent. */
>>> +sent += ret;
>>> +
>>> +/* 'sum' packet have to be retransmitted. */
>>> +sum -= ret;
>>> +}
>>> +} while (sum && (retries++ < VHOST_ENQ_RETRY_NUM));
>>> +
>>> +for (int i = 0; i < total_pkts; i++) {
>>> +dp_packet_delete(txq->vhost_burst_pkts[i]);
>>> +}
>>> +
>>> +/* Reset pkt count. */
>>> +txq->vhost_pkt_cnt = 0;
>>> +
>>> +/* 'sum' refers to packets dropped. */
>>> +return sum;
>>> +}
>>> +
>>> +/* Flush the txq if there are any packets available. */ static int
>>> +netdev_dpdk_vhost_txq_flush(struct netdev *netdev, int qid,
>>> +bool concurrent_txq OVS_UNUSED) {
>>> +struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
>>> +struct dpdk_tx_queue *txq;
>>> +
>>> +qid = dev->tx_q[qid % netdev->n_txq].map;
>>> +
>>> +/* The qid may be disabled in the guest and has been set to
>>> + * OVS_VHOST_QUEUE_DISABLED.
>>> + */
>>> +if (OVS_UNLIKELY(qid < 0)) {
>>> +return 0;
>>> +}
>>> +
>>> +txq = >tx_q[qid];
>>> +/* Increment the drop count and free the memory. */
>>> +if (OVS_UNLIKELY(!is_vhost_running(dev) ||
>>> + !(dev->flags & NETDEV_UP))) {
>>> +
>>> +if (txq->vhost_pkt_cnt) {
>>> +rte_spinlock_lock(>stats_lock);
>>> +dev->stats.tx_dropped+= txq->vhost_pkt_cnt;
>>> +rte_spinlock_unlock(>stats_lock);
>>> +
>>> +for (int i = 0; i < txq->vhost_pkt_cnt; i++) {
>>> +dp_packet_delete(txq->vhost_burst_pkts[i]);
>>
>> Spinlock (tx_lock) must be held here to avoid queue and mempool breakage.
> 
> I think you are right. tx_lock might be acquired for freeing the packets.

I think that 'vhost_pkt_cnt' reads and updates also should be protected to 
avoid races.

> ---
> rte_spinlock_lock(>tx_q[qid].tx_lock);
> for (int i = 0; i < txq->vhost_pkt_cnt; i++) {
>  dp_packet_delete(txq->vhost_burst_pkts[i]);
> }
> rte_spinlock_unlock(>tx_q[qid].tx_lock);
> 
> - Bhanuprakash
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [patch_v4] dp-packet: Reset DPDK HWOL checksum flags on init.

2017-08-09 Thread Aaron Conole
Darrell Ball  writes:

> Thanks Joe
> I forgot to add your Tested-by to V5; I have been testing this myself;
> but let me know if you would like it added – I can send a V6.

It will automatically be added by patchwork.  It is sufficient to
download (ex: https://patchwork.ozlabs.org/patch/799499/mbox)

I usually use patchwork when working on a series - if I download it from
patchwork, I can be confident that all the tags are applied properly, so
I won't forget.  Plus, all the discussion happens there, so I can
quickly browse it.

The full list is available at:
https://patchwork.ozlabs.org/project/openvswitch/list/

It would actually be cool to have a few more admins to troll patchwork
and do things like ping for status (ex:
https://patchwork.ozlabs.org/patch/719492/ is this still needed?  it
does seem to mostly apply).  Then we could make sure we don't miss
things.

> Darrell
>
> -Original Message-
> From:  on behalf of Joe Stringer 
> 
> Date: Tuesday, August 8, 2017 at 4:51 PM
> To: Darrell Ball 
> Cc: ovs dev 
> Subject: Re: [ovs-dev] [patch_v4] dp-packet: Reset DPDK HWOL checksum
> flags on init.
>
> On 8 August 2017 at 16:39, Darrell Ball  wrote:
> > Reset the DPDK HWOL checksum flags in dp_packet_init_.
> > The new HWOL bad checksum flag is uninitialized on non-dpdk ports and
> > this is noticed as test failures using netdev-dummy ports where the bad
> > checksum flag is checked.
> >
> > Fixes: 7451af618e0d ("dp-packet : Update DPDK rx checksum validation 
> functions.")
> > CC: Sugesh Chandran 
> > Signed-off-by: Darrell Ball 
> > ---
> 
> Tested-by: Joe Stringer 
> Tested-at: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_joestringer_openvswitch_jobs_262464859=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=jXM8RI10bFYBt8zzW6xxX0MRb4YxJ_uCcOdGTE0sfJo=d664GG1tgARiN5uEJxebCnczlUnMDtHdWluYN0dRc5g=
>  
> 
> I'll let those more familiar with this code provide the review.
> ___
> dev mailing list
> d...@openvswitch.org
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=jXM8RI10bFYBt8zzW6xxX0MRb4YxJ_uCcOdGTE0sfJo=kCTOzFrO_3CdwW2mM_wcQZXMHDtzpo8cAuKlHSOcxTw=
>  
> 
>
> ___
> 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] Remove duplicate description about Experimenter classes

2017-08-09 Thread Ben Pfaff
On Tue, Aug 08, 2017 at 02:55:05PM +0800, Yi Yang wrote:
> commit 3d2fbd70bda514f7327970b859663f34f994290c brought
> duplicate description about Experimenter classes
> ONFOXM_ET and NXOXM_NSH in lib/meta-flow.xml, branch-2.8
> has the same issue.
> 
> Signed-off-by: Yi Yang 

Thanks, applied to master and branch-2.8.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to support variable length

2017-08-09 Thread Yang, Yi Y
Noticed, please check the reply for that one.

-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org] 
Sent: Thursday, August 10, 2017 4:04 AM
To: Yang, Yi Y 
Cc: d...@openvswitch.org
Subject: Re: [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to support 
variable length

I gave a more detailed explanation later:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/337164.html

On Wed, Aug 09, 2017 at 07:52:38PM +, Yang, Yi Y wrote:
> Ben, no matter it is MD type 1 or MD type 2, we use the same netlink 
> attribute OVS_ACTION_ATTR_ENCAP_NSH to transfer these data, another netlink 
> attribute OVS_KEY_ATTR_NSH is for struct ovs_key_nsh. So I can't catch your 
> point, can you explain it more?
> 
> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Thursday, August 10, 2017 2:01 AM
> To: Yang, Yi Y 
> Cc: d...@openvswitch.org
> Subject: Re: [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to 
> support variable length
> 
> On Wed, Aug 09, 2017 at 07:45:13PM +0800, Yi Yang wrote:
> > In order to adapt to MD type 1 and MD type 2 at the same time and 
> > avoid breaking Linux kernel uAPI later, we change struct 
> > ovs_action_encap_nsh to the below format.
> > 
> > struct ovs_action_encap_nsh {
> > uint8_t flags;
> > uint8_t mdtype;
> > uint8_t mdlen;
> > uint8_t np;
> > __be32 path_hdr;
> > uint8_t metadata[];
> > };
> > 
> > struct ovs_action_encap_nsh will be allocated dynamically when it is 
> > used.
> > 
> > The following patch will change encap_nsh and decap_nsh into 
> > push_nsh and pop_nsh, respectively, Linux kernel guys prefer
> > push_* and pop_*.
> > 
> > Signed-off-by: Yi Yang 
> 
> This is an unusual format for a Netlink attribute.  More commonly, one would 
> put variable-length data into an attribute of its own, which allows that data 
> to be handled using the regular Netlink means.  Then the mdlen and metadata 
> members could be removed, since they would be part of the additional 
> attribute, and one might expect the mdtype member to be removed as well since 
> each type of metadata would be in a different attribute type.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 1/2] travis: Explicitly disable LLVM for sparse build.

2017-08-09 Thread Lance Richardson
> From: "Ben Pfaff" 
> To: d...@openvswitch.org
> Cc: "Ben Pfaff" 
> Sent: Thursday, July 27, 2017 4:41:05 PM
> Subject: [ovs-dev] [PATCH 1/2] travis: Explicitly disable LLVM for sparse 
> build.
> 
> Newer travis environments claim to have LLVM support (llvm-config exists
> and works) but in reality don't, which prevents sparse from building and
> later parts of the build from succeeding.
> 
> Signed-off-by: Ben Pfaff 
> ---

I don't know what the symptom of this failure was, but some branch-2.6 and 
branch-2.7
travis builds are failing with:

   env: cgcc: No such file or directory

Should this be back-ported to other branches?

Thanks,

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


[ovs-dev] [PATCH trivial 3/3] ovn-northd: Fix minor style variation.

2017-08-09 Thread Joe Stringer
Signed-off-by: Joe Stringer 
---
 ovn/northd/ovn-northd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 99d15a7a56c4..49e4ac3383d3 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -1886,7 +1886,7 @@ ovn_port_update_sbrec(struct northd_context *ctx,
 if (chassis) {
 /* If we found the chassis, and the gw chassis on record
  * differs from what we expect go ahead and update */
-if (op->sb->n_gateway_chassis !=1
+if (op->sb->n_gateway_chassis != 1
 || strcmp(op->sb->gateway_chassis[0]->chassis->name,
   chassis->name)
 || op->sb->gateway_chassis[0]->priority != 0) {
-- 
2.13.3

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


[ovs-dev] [PATCH v2] python: make python idl unicode-tolerant

2017-08-09 Thread Lance Richardson
Ensure that JSON is utf-8 encoded and that bytes sent/received on
the stream sockets are in utf-8 form. Add a test case to verify
that unicode data can be sent/received successfully using Python
IDL module.

Co-authored-by: Terry Wilson 
Signed-off-by: Terry Wilson 
Signed-off-by: Lance Richardson 
---
v1-v2:
  - Changed a unicode string in ovsdb-idl.at to avoid an issue
in some installations of gnome-terminal (coredump).
  - Fixed a flake8 line length warning in test-ovsdb.py.
  - Added co-authored-by/acked-by for Terry Wilson (was
suggested-by).

 python/ovs/json.py|  9 +++--
 python/ovs/jsonrpc.py |  3 +--
 python/ovs/stream.py  |  6 --
 tests/ovsdb-idl.at| 13 +
 tests/test-ovsdb.py   |  6 +-
 5 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/python/ovs/json.py b/python/ovs/json.py
index 37ea9cf38..e84063fc2 100644
--- a/python/ovs/json.py
+++ b/python/ovs/json.py
@@ -29,8 +29,13 @@ except ImportError:
 __pychecker__ = 'no-stringiter'
 
 SPACES_PER_LEVEL = 2
-dumper = functools.partial(json.dumps, separators=(",", ":"),
-   ensure_ascii=False)
+_dumper = functools.partial(json.dumps, separators=(",", ":"))
+
+if six.PY2:
+def dumper(*args, **kwargs):
+return _dumper(*args, **kwargs).decode('raw-unicode-escape')
+else:
+dumper = _dumper
 
 
 def to_stream(obj, stream, pretty=False, sort_keys=True):
diff --git a/python/ovs/jsonrpc.py b/python/ovs/jsonrpc.py
index 09e9c8b0a..d284190e0 100644
--- a/python/ovs/jsonrpc.py
+++ b/python/ovs/jsonrpc.py
@@ -268,8 +268,7 @@ class Connection(object):
 # Python 3 has separate types for strings and bytes.  We
 # received bytes from a socket.  We expect it to be string
 # data, so we convert it here as soon as possible.
-if (data and not error
-and not isinstance(data, six.string_types)):
+if data and not error:
 try:
 data = data.decode('utf-8')
 except UnicodeError:
diff --git a/python/ovs/stream.py b/python/ovs/stream.py
index 660d8bbf2..57e7a6eef 100644
--- a/python/ovs/stream.py
+++ b/python/ovs/stream.py
@@ -386,8 +386,10 @@ class Stream(object):
 try:
 # Python 3 has separate types for strings and bytes.  We must have
 # bytes here.
-if six.PY3 and not isinstance(buf, six.binary_type):
-buf = six.binary_type(buf, 'utf-8')
+if six.PY3 and not isinstance(buf, bytes):
+buf = bytes(buf, 'utf-8')
+elif six.PY2:
+buf = buf.encode('utf-8')
 return self.socket.send(buf)
 except socket.error as e:
 return -ovs.socket_util.get_exception_errno(e)
diff --git a/tests/ovsdb-idl.at b/tests/ovsdb-idl.at
index 920feb471..a5f75febf 100644
--- a/tests/ovsdb-idl.at
+++ b/tests/ovsdb-idl.at
@@ -315,6 +315,19 @@ OVSDB_CHECK_IDL([simple idl, writing via IDL],
 005: done
 ]])
 
+OVSDB_CHECK_IDL([simple idl, writing via IDL with unicode],
+  [['["idltest",
+  {"op": "insert",
+   "table": "simple",
+   "row": {"s": "(╯°□°)╯︵ ┻━┻"}}]']],
+  [['set 0 b 1, insert 1, set 1 s "¯\_(ツ)_/¯"']],
+  [[000: i=0 r=0 b=false s=(╯°□°)╯︵ ┻━┻ u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] 
uuid=<1>
+001: commit, status=success
+002: i=0 r=0 b=true s=(╯°□°)╯︵ ┻━┻ u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] uuid=<1>
+002: i=1 r=0 b=false s="¯\_(ツ)_/¯" u=<0> ia=[] ra=[] ba=[] sa=[] ua=[] uuid=<2>
+003: done
+]])
+
 OVSDB_CHECK_IDL([simple idl, handling verification failure],
   [['["idltest",
   {"op": "insert",
diff --git a/tests/test-ovsdb.py b/tests/test-ovsdb.py
index 4dcc91e91..df9d6d58c 100644
--- a/tests/test-ovsdb.py
+++ b/tests/test-ovsdb.py
@@ -334,7 +334,11 @@ def idl_set(idl, commands, step):
 if args[1] == "b":
 s.b = args[2] == "1"
 elif args[1] == "s":
-s.s = args[2]
+if six.PY2:
+s.s = args[2].decode('utf-8')
+else:
+s.s = args[2].encode('utf-8', 'surrogateescape') \
+ .decode('utf-8', 'replace')
 elif args[1] == "u":
 s.u = uuid.UUID(args[2])
 elif args[1] == "r":
-- 
2.13.3

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


Re: [ovs-dev] [PATCH] python: make python idl unicode-tolerant

2017-08-09 Thread Russell Bryant
On Wed, Aug 9, 2017 at 3:32 PM, Ben Pfaff  wrote:
> On Wed, Aug 09, 2017 at 03:27:32PM -0400, Russell Bryant wrote:
>> On Tue, Aug 8, 2017 at 2:44 PM, Lance Richardson  wrote:
>> > Ensure that JSON is utf-8 encoded and that bytes sent/received on
>> > the stream sockets are in utf-8 form. Add a test case to verify
>> > that unicode column data can be sent/received successfully using
>> > Python module.
>> >
>> > JSON encoder magic to ensure utf-8 encoding  suggested by Terry
>> > Wilson.
>> >
>> > Suggested-by: Terry Wilson 
>> > Signed-off-by: Lance Richardson 
>> > ---
>> >  python/ovs/json.py|  9 +++--
>> >  python/ovs/jsonrpc.py |  3 +--
>> >  python/ovs/stream.py  |  6 --
>> >  tests/ovsdb-idl.at| 13 +
>> >  tests/test-ovsdb.py   |  5 -
>> >  5 files changed, 29 insertions(+), 7 deletions(-)
>>
>> We discussed this patch on IRC, but for the record:
>>
>> There's a line in test-ovsdb.py that's too long.  flake8 complained
>> about it for me.
>>
>> The changes to ovsdb-idl.at contain some unicode that my terminal
>> chokes on.  After spending far too much time trying to figure out why,
>> I was able to work around it by changing the crazy face to an
>> appropriate alternative which seems to work OK: (╯°□°)╯︵ ┻━┻
>
> Russell, do you want to handle the review for this?  It looks OK to me
> but it sounds like you have some specific changes to make, so I think
> you should go for it.

Yeah, I'll handle this one.  Thanks.

It looked OK for me other than how it made my terminal crash when I
tried to view it.  :-)

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


Re: [ovs-dev] [patch_v4] dp-packet: Reset DPDK HWOL checksum flags on init.

2017-08-09 Thread Joe Stringer
On 8 August 2017 at 19:10, Darrell Ball  wrote:
> Thanks Joe
> I forgot to add your Tested-by to V5; I have been testing this myself; but 
> let me know if you would like it added – I can send a V6.

No worries, it looks like you'll resubmit with a slightly different
approach so feel free to drop these tested tags as they're no longer
applicable.

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


Re: [ovs-dev] [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to support variable length

2017-08-09 Thread Yang, Yi Y
Ben, no matter it is MD type 1 or MD type 2, we use the same netlink attribute 
OVS_ACTION_ATTR_ENCAP_NSH to transfer these data, another netlink attribute 
OVS_KEY_ATTR_NSH is for struct ovs_key_nsh. So I can't catch your point, can 
you explain it more?

-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org] 
Sent: Thursday, August 10, 2017 2:01 AM
To: Yang, Yi Y 
Cc: d...@openvswitch.org
Subject: Re: [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to support 
variable length

On Wed, Aug 09, 2017 at 07:45:13PM +0800, Yi Yang wrote:
> In order to adapt to MD type 1 and MD type 2 at the same time and 
> avoid breaking Linux kernel uAPI later, we change struct 
> ovs_action_encap_nsh to the below format.
> 
> struct ovs_action_encap_nsh {
> uint8_t flags;
> uint8_t mdtype;
> uint8_t mdlen;
> uint8_t np;
> __be32 path_hdr;
> uint8_t metadata[];
> };
> 
> struct ovs_action_encap_nsh will be allocated dynamically when it is 
> used.
> 
> The following patch will change encap_nsh and decap_nsh into push_nsh 
> and pop_nsh, respectively, Linux kernel guys prefer
> push_* and pop_*.
> 
> Signed-off-by: Yi Yang 

This is an unusual format for a Netlink attribute.  More commonly, one would 
put variable-length data into an attribute of its own, which allows that data 
to be handled using the regular Netlink means.  Then the mdlen and metadata 
members could be removed, since they would be part of the additional attribute, 
and one might expect the mdtype member to be removed as well since each type of 
metadata would be in a different attribute type.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to support variable length

2017-08-09 Thread Ben Pfaff
I gave a more detailed explanation later:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/337164.html

On Wed, Aug 09, 2017 at 07:52:38PM +, Yang, Yi Y wrote:
> Ben, no matter it is MD type 1 or MD type 2, we use the same netlink 
> attribute OVS_ACTION_ATTR_ENCAP_NSH to transfer these data, another netlink 
> attribute OVS_KEY_ATTR_NSH is for struct ovs_key_nsh. So I can't catch your 
> point, can you explain it more?
> 
> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org] 
> Sent: Thursday, August 10, 2017 2:01 AM
> To: Yang, Yi Y 
> Cc: d...@openvswitch.org
> Subject: Re: [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to 
> support variable length
> 
> On Wed, Aug 09, 2017 at 07:45:13PM +0800, Yi Yang wrote:
> > In order to adapt to MD type 1 and MD type 2 at the same time and 
> > avoid breaking Linux kernel uAPI later, we change struct 
> > ovs_action_encap_nsh to the below format.
> > 
> > struct ovs_action_encap_nsh {
> > uint8_t flags;
> > uint8_t mdtype;
> > uint8_t mdlen;
> > uint8_t np;
> > __be32 path_hdr;
> > uint8_t metadata[];
> > };
> > 
> > struct ovs_action_encap_nsh will be allocated dynamically when it is 
> > used.
> > 
> > The following patch will change encap_nsh and decap_nsh into push_nsh 
> > and pop_nsh, respectively, Linux kernel guys prefer
> > push_* and pop_*.
> > 
> > Signed-off-by: Yi Yang 
> 
> This is an unusual format for a Netlink attribute.  More commonly, one would 
> put variable-length data into an attribute of its own, which allows that data 
> to be handled using the regular Netlink means.  Then the mdlen and metadata 
> members could be removed, since they would be part of the additional 
> attribute, and one might expect the mdtype member to be removed as well since 
> each type of metadata would be in a different attribute type.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support

2017-08-09 Thread Yang, Yi Y
Ben, do you mean we bring two new attributes (OVS_NSH_ATTR_MD1 and   
OVS_NSH_ATTR_MD2) and embed one of them in OVS_ACTION_ATTR_ENCAP_NSH? Anyway we 
need to use a struct or something else to transfer those metadata between 
functions, how do you think we can handle this without metadata in struct 
ovs_action_encap_nsh? I mean how we handle the arguments for function encap_nsh.

-Original Message-
From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On 
Behalf Of Ben Pfaff
Sent: Thursday, August 10, 2017 2:09 AM
To: Yang, Yi Y 
Cc: Jan Scheurich ; d...@openvswitch.org; 
net...@vger.kernel.org; Jiri Benc ; da...@davemloft.net; 
Zoltán Balogh 
Subject: Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support

On Wed, Aug 09, 2017 at 09:41:51AM +, Yang, Yi Y wrote:
> Hi,  Jan
> 
> I have worked out a patch, will send it quickly for Ben. In addition, 
> I also will send out a patch to change encap_nsh _nsh to 
> push_nsh and pop_nsh. Per comments from all the people, we all agreed 
> to do so :-)
> 
> diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
> b/datapath/linux/compat/include/linux/openvswitch.h
> index bc6c94b..4936c12 100644
> --- a/datapath/linux/compat/include/linux/openvswitch.h
> +++ b/datapath/linux/compat/include/linux/openvswitch.h
> @@ -793,7 +793,7 @@ struct ovs_action_push_eth {
> struct ovs_key_ethernet addresses;  };
> 
> -#define OVS_ENCAP_NSH_MAX_MD_LEN 16
> +#define OVS_ENCAP_NSH_MAX_MD_LEN 248
>  /*
>   * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
>   * @flags: NSH header flags.
> @@ -809,7 +809,7 @@ struct ovs_action_encap_nsh {
>  uint8_t mdlen;
>  uint8_t np;
>  __be32 path_hdr;
> -uint8_t metadata[OVS_ENCAP_NSH_MAX_MD_LEN];
> +uint8_t metadata[];
>  };

This brings the overall format of ovs_action_encap_nsh to:

struct ovs_action_encap_nsh {
uint8_t flags;
uint8_t mdtype;
uint8_t mdlen;
uint8_t np;
__be32 path_hdr;
uint8_t metadata[];
};

This is an unusual format for a Netlink attribute.  More commonly, one would 
put variable-length data into an attribute of its own, which allows that data 
to be handled using the regular Netlink means.  Then the mdlen and metadata 
members could be removed, since they would be part of the additional attribute, 
and one might expect the mdtype member to be removed as well since each type of 
metadata would be in a different attribute type.

So, a format closer to what I expect to see in Netlink is something like
this:

/**
 * enum ovs_nsh_attr - Metadata attributes for %OVS_ACTION_ENCAP_NSH action.
 *
 * @OVS_NSH_ATTR_MD1: Contains 16-byte NSH type-1 metadata.
 * @OVS_NSH_ATTR_MD2: Contains 0- to 255-byte variable-length NSH type-2
 * metadata. */
enum ovs_nsh_attr {
OVS_NSH_ATTR_MD1,
OVS_NSH_ATTR_MD2
};

/*
 * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
 *
 * @path_hdr: NSH service path id and service index.
 * @flags: NSH header flags.
 * @np: NSH next_protocol: Inner packet type.
 *
 * Followed by either %OVS_NSH_ATTR_MD1 or %OVS_NSH_ATTR_MD2 attribute.
 */
struct ovs_action_encap_nsh {
__be32 path_hdr;
uint8_t flags;
uint8_t np;
};
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH trivial 1/3] netdev-dummy: Fix minor style variation.

2017-08-09 Thread Joe Stringer
Signed-off-by: Joe Stringer 
---
 lib/netdev-dummy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/netdev-dummy.c b/lib/netdev-dummy.c
index 62ddd0c67834..f731af1dfd0e 100644
--- a/lib/netdev-dummy.c
+++ b/lib/netdev-dummy.c
@@ -1574,7 +1574,7 @@ netdev_dummy_receive(struct unixctl_conn *conn,
 unixctl_command_reply_error(conn, "too small packet len");
 goto exit;
 }
-i+=2;
+i += 2;
 }
 /* Try parse 'argv[i]' as odp flow. */
 packet = eth_from_flow(flow_str, packet_size);
-- 
2.13.3

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


[ovs-dev] [PATCH 3/3] checkpatch: Check for trailing operators.

2017-08-09 Thread Joe Stringer
The style guide states that lines should not end with '?' or ':'. Check
for this and report an error.

Signed-off-by: Joe Stringer 
---
v2: Restrict to '?' and ':'.
Make sure that goto tags aren't flagged.
---
 utilities/checkpatch.py | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/utilities/checkpatch.py b/utilities/checkpatch.py
index 1bb256ccd4d6..e553076d7d1c 100755
--- a/utilities/checkpatch.py
+++ b/utilities/checkpatch.py
@@ -94,6 +94,7 @@ __regex_ends_with_bracket = \
 re.compile(r'[^\s]\) {(\s+/\*[\s\Sa-zA-Z0-9\.,\?\*/+-]*)?$')
 __regex_ptr_declaration_missing_whitespace = re.compile(r'[a-zA-Z0-9]\*[^*]')
 __regex_is_comment_line = re.compile(r'^\s*(/\*|\*\s)')
+__regex_trailing_operator = re.compile(r'^[^ ]* [^ ]*[?:]$')
 
 skip_leading_whitespace_check = False
 skip_trailing_whitespace_check = False
@@ -206,6 +207,11 @@ def is_comment_line(line):
 return __regex_is_comment_line.match(line) is not None
 
 
+def trailing_operator(line):
+"""Returns TRUE if the current line ends with an operator, eg &&"""
+return __regex_trailing_operator.match(line) is not None
+
+
 checks = [
 {'regex': None,
  'match_name':
@@ -237,7 +243,13 @@ checks = [
  'prereq': lambda x: not is_comment_line(x),
  'check': lambda x: pointer_whitespace_check(x),
  'print':
- lambda: print_error("Inappropriate spacing in pointer declaration")}
+ lambda: print_error("Inappropriate spacing in pointer declaration")},
+
+{'regex': '(\.c|\.h)(\.in)?$', 'match_name': None,
+ 'prereq': lambda x: not is_comment_line(x),
+ 'check': lambda x: trailing_operator(x),
+ 'print':
+ lambda: print_error("Line has '?' or ':' operator at end of line")},
 ]
 
 
-- 
2.13.3

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


Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum flags on init.

2017-08-09 Thread Darrell Ball


-Original Message-
From: "Chandran, Sugesh" 
Date: Wednesday, August 9, 2017 at 12:55 PM
To: Darrell Ball , Ben Pfaff 
Cc: "d...@openvswitch.org" 
Subject: RE: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum flags on 
init.



Regards
_Sugesh


> > >
> > > Correct, I reused reset_dp_packet_checksum_ol_flags() to do 
the
> > initialization as well
> > > I could also have created a separate function.
> > >
> > > In case a DPDK dev is used, those flags will be managed by 
DPDK.
> > >
> > >  That sounds like a
> > > bug in itself--is there a missing call to initialize the 
mbuf
> somewhere?
> > >
> > > Are you suggesting to initialize the whole mbuf for each 
packet ?
> >
> > The issue that I'm raising is that it's unusual to take an
> > uninitialized, indeterminate field, and then initialize it by 
clearing a
> > few bits.  It's much more conventional to initialize it by 
setting it to
> > zero, like this:
> >
> > p->mbuf.ol_flags = 0;
> >
> >
> > That is better; I will create a separate function then.
> > I will resend
> > Thanks
> [Sugesh] I also agree with Ben here.
> Currently OVS uses only checksum offload flags from mbuf(As I am aware
> of).
> But there are other flag bits that may get used in future like TSO.
> So its better to initialize the mbuf properly before using.
> 
> Here is the mbuf reset function in DPDK that get called when an 
existing
> memory is mapped to
> Mbuf.
> I believe only the ol_flags are relevant for now in OVS.
> 
> There is no higher cost associated with initializing all the ol_flags vs 
some
> flags, so that is fine.
> It will be done twice in the case of a packet received from a dpdk 
device, but
> it is a small cost.
> I was more concerned about the dual responsibility conflict when packets 
are
> received from a DPDK device and this is why I wanted to limit the scope of
> the flag management in OVS; it should be ok, though.
> Hence, I mentioned that I will initialize all the ol_flags.
> 
> JTBC, are you suggesting to initialize all the fields below ?
> This would mean when packets are received from a DPDK dev, both the rte
> library and OVS would separately initialize all the fields below – 
meaning, it
> would be done twice for each packet.
> 
[Sugesh] No, we don’t have to initialize all the fields. But we can have a 
generic function
to init all mbuf fields that are relevant in OVS. 
For now its only ol_flags. In the future this function must be updated when 
we use more
fields from rte_mbuf.

We are on the same page then.
I plan for the function to have a generic name, so this fine.


Sorry, I really didn’t get the case you mentioned above, where the init get 
called twice.
What I can see in the code is , during the dpdk mp init, the 
the dp_packet_init is called for rte_mbuf initialization. This happens at 
port initiation.

On packet reception, there wont any call to dp_packet_init.

I meant for the memory related to packets that are received, not during the 
reception time itself.
However, the memory will be reused for subsequent packets, right. You can’t use 
a piece of memory
once and never use it again – this is called a memory leak. This means each 
mbuf will need to be initialized again and again.


> 
> static inline void rte_pktmbuf_reset(struct rte_mbuf *m)
> {
> m->next = NULL;
> m->pkt_len = 0;
> m->tx_offload = 0;
> m->vlan_tci = 0;
> m->vlan_tci_outer = 0;
> m->nb_segs = 1;
> m->port = 0xff;
> 
> m->ol_flags = 0;
> m->packet_type = 0;
> rte_pktmbuf_reset_headroom(m);
> 
> m->data_len = 0;
> __rte_mbuf_sanity_check(m, 1);
> }
> 
> >
> >
> > That made me wonder whether there's a larger problem of a 
failure to
> > initialize the mbuf more generally, although of course that 
does not
> > necessarily follow.
> >
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__mail.openvswitch.org_mailman_listinfo_ovs-
> 2Ddev=DwIFAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-
> uZnsw=wM40bZgtG4Ul1nb53ufLGymPOplaXttP5W6_wL2w_XA=05T6d
> 75pGHINP78-6gwS87E3IhAXzHojsFzyNSDdaTY=
> 






Re: [ovs-dev] [PATCH trivial 1/3] netdev-dummy: Fix minor style variation.

2017-08-09 Thread Ben Pfaff
On Wed, Aug 09, 2017 at 01:38:05PM -0700, Joe Stringer wrote:
> Signed-off-by: Joe Stringer 

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


Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support

2017-08-09 Thread Ben Pfaff
On Wed, Aug 09, 2017 at 08:12:36PM +, Yang, Yi Y wrote:
> Ben, do you mean we bring two new attributes (OVS_NSH_ATTR_MD1 and
> OVS_NSH_ATTR_MD2) and embed one of them in OVS_ACTION_ATTR_ENCAP_NSH?

Yes.

> Anyway we need to use a struct or something else to transfer those
> metadata between functions, how do you think we can handle this
> without metadata in struct ovs_action_encap_nsh? I mean how we handle
> the arguments for function encap_nsh.

I guess that a pointer to the embedded nlattr with type OVS_NSH_ATTR_MD1
or OVS_NSH_ATTR2 should work OK.

Keep in mind that I'm not a kernel-side maintainer of any kind.  I am
only passing along what I've perceived to be common Netlink protocol
design patterns.

> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On 
> Behalf Of Ben Pfaff
> Sent: Thursday, August 10, 2017 2:09 AM
> To: Yang, Yi Y 
> Cc: Jan Scheurich ; d...@openvswitch.org; 
> net...@vger.kernel.org; Jiri Benc ; da...@davemloft.net; 
> Zoltán Balogh 
> Subject: Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support
> 
> On Wed, Aug 09, 2017 at 09:41:51AM +, Yang, Yi Y wrote:
> > Hi,  Jan
> > 
> > I have worked out a patch, will send it quickly for Ben. In addition, 
> > I also will send out a patch to change encap_nsh _nsh to 
> > push_nsh and pop_nsh. Per comments from all the people, we all agreed 
> > to do so :-)
> > 
> > diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
> > b/datapath/linux/compat/include/linux/openvswitch.h
> > index bc6c94b..4936c12 100644
> > --- a/datapath/linux/compat/include/linux/openvswitch.h
> > +++ b/datapath/linux/compat/include/linux/openvswitch.h
> > @@ -793,7 +793,7 @@ struct ovs_action_push_eth {
> > struct ovs_key_ethernet addresses;  };
> > 
> > -#define OVS_ENCAP_NSH_MAX_MD_LEN 16
> > +#define OVS_ENCAP_NSH_MAX_MD_LEN 248
> >  /*
> >   * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
> >   * @flags: NSH header flags.
> > @@ -809,7 +809,7 @@ struct ovs_action_encap_nsh {
> >  uint8_t mdlen;
> >  uint8_t np;
> >  __be32 path_hdr;
> > -uint8_t metadata[OVS_ENCAP_NSH_MAX_MD_LEN];
> > +uint8_t metadata[];
> >  };
> 
> This brings the overall format of ovs_action_encap_nsh to:
> 
> struct ovs_action_encap_nsh {
> uint8_t flags;
> uint8_t mdtype;
> uint8_t mdlen;
> uint8_t np;
> __be32 path_hdr;
> uint8_t metadata[];
> };
> 
> This is an unusual format for a Netlink attribute.  More commonly, one would 
> put variable-length data into an attribute of its own, which allows that data 
> to be handled using the regular Netlink means.  Then the mdlen and metadata 
> members could be removed, since they would be part of the additional 
> attribute, and one might expect the mdtype member to be removed as well since 
> each type of metadata would be in a different attribute type.
> 
> So, a format closer to what I expect to see in Netlink is something like
> this:
> 
> /**
>  * enum ovs_nsh_attr - Metadata attributes for %OVS_ACTION_ENCAP_NSH action.
>  *
>  * @OVS_NSH_ATTR_MD1: Contains 16-byte NSH type-1 metadata.
>  * @OVS_NSH_ATTR_MD2: Contains 0- to 255-byte variable-length NSH type-2
>  * metadata. */
> enum ovs_nsh_attr {
> OVS_NSH_ATTR_MD1,
> OVS_NSH_ATTR_MD2
> };
> 
> /*
>  * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
>  *
>  * @path_hdr: NSH service path id and service index.
>  * @flags: NSH header flags.
>  * @np: NSH next_protocol: Inner packet type.
>  *
>  * Followed by either %OVS_NSH_ATTR_MD1 or %OVS_NSH_ATTR_MD2 attribute.
>  */
> struct ovs_action_encap_nsh {
> __be32 path_hdr;
> uint8_t flags;
> uint8_t np;
> };
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 2/3] checkpatch: Fix matching on C filenames.

2017-08-09 Thread Ben Pfaff
On Wed, Aug 09, 2017 at 01:37:51PM -0700, Joe Stringer wrote:
> Most of the prerequisite checks so far matched on filenames that ended
> in some character followed by 'c' or 'h', rather than a filename that
> ends in '.c' or '.h'. Fix this.
> 
> Signed-off-by: Joe Stringer 

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


Re: [ovs-dev] [PATCH 1/3] checkpatch: Check for infix operator whitespace.

2017-08-09 Thread Ben Pfaff
On Wed, Aug 09, 2017 at 01:37:50PM -0700, Joe Stringer wrote:
> The 'Expressions' section of the coding style specifies that one space
> should be on either side of infix binary and ternary operators. This
> adds a check to checkpatch.py for most of these.
> 
> The regex won't match if there are speech marks on the line, because
> the style should not apply to the contents of strings.
> 
> This check is left at warning level because there isn't a good way to
> determine whether a line is within a multiline comment or string, so it
> will occasionally flag such lines which contain hyphenated words.
> 
> Signed-off-by: Joe Stringer 

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


Re: [ovs-dev] [PATCH] python: make python idl unicode-tolerant

2017-08-09 Thread Russell Bryant
On Tue, Aug 8, 2017 at 2:44 PM, Lance Richardson  wrote:
> Ensure that JSON is utf-8 encoded and that bytes sent/received on
> the stream sockets are in utf-8 form. Add a test case to verify
> that unicode column data can be sent/received successfully using
> Python module.
>
> JSON encoder magic to ensure utf-8 encoding  suggested by Terry
> Wilson.
>
> Suggested-by: Terry Wilson 
> Signed-off-by: Lance Richardson 
> ---
>  python/ovs/json.py|  9 +++--
>  python/ovs/jsonrpc.py |  3 +--
>  python/ovs/stream.py  |  6 --
>  tests/ovsdb-idl.at| 13 +
>  tests/test-ovsdb.py   |  5 -
>  5 files changed, 29 insertions(+), 7 deletions(-)

We discussed this patch on IRC, but for the record:

There's a line in test-ovsdb.py that's too long.  flake8 complained
about it for me.

The changes to ovsdb-idl.at contain some unicode that my terminal
chokes on.  After spending far too much time trying to figure out why,
I was able to work around it by changing the crazy face to an
appropriate alternative which seems to work OK: (╯°□°)╯︵ ┻━┻
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] python: make python idl unicode-tolerant

2017-08-09 Thread Ben Pfaff
On Wed, Aug 09, 2017 at 03:27:32PM -0400, Russell Bryant wrote:
> On Tue, Aug 8, 2017 at 2:44 PM, Lance Richardson  wrote:
> > Ensure that JSON is utf-8 encoded and that bytes sent/received on
> > the stream sockets are in utf-8 form. Add a test case to verify
> > that unicode column data can be sent/received successfully using
> > Python module.
> >
> > JSON encoder magic to ensure utf-8 encoding  suggested by Terry
> > Wilson.
> >
> > Suggested-by: Terry Wilson 
> > Signed-off-by: Lance Richardson 
> > ---
> >  python/ovs/json.py|  9 +++--
> >  python/ovs/jsonrpc.py |  3 +--
> >  python/ovs/stream.py  |  6 --
> >  tests/ovsdb-idl.at| 13 +
> >  tests/test-ovsdb.py   |  5 -
> >  5 files changed, 29 insertions(+), 7 deletions(-)
> 
> We discussed this patch on IRC, but for the record:
> 
> There's a line in test-ovsdb.py that's too long.  flake8 complained
> about it for me.
> 
> The changes to ovsdb-idl.at contain some unicode that my terminal
> chokes on.  After spending far too much time trying to figure out why,
> I was able to work around it by changing the crazy face to an
> appropriate alternative which seems to work OK: (╯°□°)╯︵ ┻━┻

Russell, do you want to handle the review for this?  It looks OK to me
but it sounds like you have some specific changes to make, so I think
you should go for it.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH V3 0/2] Fix for dumping vxlan flows from ovs-dpctl

2017-08-09 Thread Ben Pfaff
On Tue, Aug 08, 2017 at 05:03:10PM +0300, Roi Dayan wrote:
> Hi,
> 
> The first patch is to avoid false errors about getting ifindex
> as the device might disappear already.
> The second patch is a fix for dumping vxlan rules with ovs-dpctl.

Thanks for the fixing.  I applied these patches to master and
branch-2.8.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] python: make python idl unicode-tolerant

2017-08-09 Thread Ben Pfaff
On Wed, Aug 09, 2017 at 03:42:05PM -0400, Russell Bryant wrote:
> It looked OK for me other than how it made my terminal crash when I
> tried to view it.  :-)

It sounds like you should report a bug to the terminal emulator
maintainers.  Output shouldn't be able to crash a terminal.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v2] python: make python idl unicode-tolerant

2017-08-09 Thread Russell Bryant
On Wed, Aug 9, 2017 at 3:38 PM, Lance Richardson  wrote:
> Ensure that JSON is utf-8 encoded and that bytes sent/received on
> the stream sockets are in utf-8 form. Add a test case to verify
> that unicode data can be sent/received successfully using Python
> IDL module.
>
> Co-authored-by: Terry Wilson 
> Signed-off-by: Terry Wilson 
> Signed-off-by: Lance Richardson 
> ---
> v1-v2:
>   - Changed a unicode string in ovsdb-idl.at to avoid an issue
> in some installations of gnome-terminal (coredump).
>   - Fixed a flake8 line length warning in test-ovsdb.py.
>   - Added co-authored-by/acked-by for Terry Wilson (was
> suggested-by).
>
>  python/ovs/json.py|  9 +++--
>  python/ovs/jsonrpc.py |  3 +--
>  python/ovs/stream.py  |  6 --
>  tests/ovsdb-idl.at| 13 +
>  tests/test-ovsdb.py   |  6 +-
>  5 files changed, 30 insertions(+), 7 deletions(-)

Thanks, applied to master, branch-2.8, and branch-2.7.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] AdvancedMD Users List

2017-08-09 Thread Kristina
Hi,

 

I was curious to know if you would be interested in AdvancedMD Users List
2017?

 

Let me know your target criteria and we will revert back to you with further
details.

 

Target Users:

Geography:

 

Looking forward to continued success with you.

 

Regards,

Kristina Jones | Marketing Analyst

 

 

If you have any other unique requirement please feel free to share your
requirement with us as we can help you with on-demand list customized as per
your requirement.

 

 

To remove from this mailing: reply with subject line as "leave out"

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


Re: [ovs-dev] [PATCH 1/2] travis: Explicitly disable LLVM for sparse build.

2017-08-09 Thread Ben Pfaff
On Wed, Aug 09, 2017 at 04:36:42PM -0400, Lance Richardson wrote:
> > From: "Ben Pfaff" 
> > To: d...@openvswitch.org
> > Cc: "Ben Pfaff" 
> > Sent: Thursday, July 27, 2017 4:41:05 PM
> > Subject: [ovs-dev] [PATCH 1/2] travis: Explicitly disable LLVM for sparse   
> > build.
> > 
> > Newer travis environments claim to have LLVM support (llvm-config exists
> > and works) but in reality don't, which prevents sparse from building and
> > later parts of the build from succeeding.
> > 
> > Signed-off-by: Ben Pfaff 
> > ---
> 
> I don't know what the symptom of this failure was, but some branch-2.6 and 
> branch-2.7
> travis builds are failing with:
> 
>env: cgcc: No such file or directory
> 
> Should this be back-ported to other branches?

Thanks for the note.  Done.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 3/3] checkpatch: Check for trailing operators.

2017-08-09 Thread Ben Pfaff
On Wed, Aug 09, 2017 at 01:37:52PM -0700, Joe Stringer wrote:
> The style guide states that lines should not end with '?' or ':'. Check
> for this and report an error.
> 
> Signed-off-by: Joe Stringer 

The comment should be updated since the style considers && at the end of
a line to be OK:
> +"""Returns TRUE if the current line ends with an operator, eg &&"""

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


Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum flags on init.

2017-08-09 Thread Darrell Ball


-Original Message-
From: "Chandran, Sugesh" 
Date: Wednesday, August 9, 2017 at 11:17 AM
To: Darrell Ball , Ben Pfaff 
Cc: "d...@openvswitch.org" 
Subject: RE: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum flags on 
init.

Hi Darrel,

I reviewed and tested the patch.
It does fixed the UT failures in --with-dpdk case.

One comment below.

Regards
_Sugesh


> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of Darrell Ball
> Sent: Wednesday, August 9, 2017 6:58 PM
> To: Ben Pfaff 
> Cc: d...@openvswitch.org
> Subject: Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum
> flags on init.
> 
> 
> 
> -Original Message-
> From: Ben Pfaff 
> Date: Wednesday, August 9, 2017 at 10:40 AM
> To: Darrell Ball 
> Cc: Darrell Ball , "d...@openvswitch.org"
> 
> Subject: Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum
> flags on init.
> 
> On Wed, Aug 09, 2017 at 05:32:02PM +, Darrell Ball wrote:
> >
> >
> > -Original Message-
> > From:  on behalf of Ben Pfaff
> 
> > Date: Wednesday, August 9, 2017 at 10:15 AM
> > To: Darrell Ball 
> > Cc: "d...@openvswitch.org" 
> > Subject: Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL
> checksum flags on init.
> >
> > On Tue, Aug 08, 2017 at 06:54:46PM -0700, Darrell Ball wrote:
> > > Reset the DPDK HWOL checksum flags in dp_packet_init_.
> > > The new HWOL bad checksum flag is uninitialized for non-dpdk 
ports
> and
> > > this is noticed as test failures using netdev-dummy ports, 
when built
> with
> > > the --with-dpdk flag set. Hence, in this case, packets may be 
marked
> as
> > > having a bad checksum.
> >
> > > diff --git a/lib/dp-packet.c b/lib/dp-packet.c
> > > index 67aa406..4926993 100644
> > > --- a/lib/dp-packet.c
> > > +++ b/lib/dp-packet.c
> > > @@ -31,6 +31,7 @@ dp_packet_init__(struct dp_packet *b, size_t
> allocated, enum dp_packet_source so
> > >  dp_packet_reset_offsets(b);
> > >  pkt_metadata_init(>md, 0);
> > >  dp_packet_rss_invalidate(b);
> > > +reset_dp_packet_checksum_ol_flags(b);
> >
> > This function un-sets some bits in p->mbuf.ol_flags.  The need 
for this
> > implies that nothing initializes p->mbuf.ol_flags.
> >
> > Correct, I reused reset_dp_packet_checksum_ol_flags() to do the
> initialization as well
> > I could also have created a separate function.
> >
> > In case a DPDK dev is used, those flags will be managed by DPDK.
> >
> >  That sounds like a
> > bug in itself--is there a missing call to initialize the mbuf 
somewhere?
> >
> > Are you suggesting to initialize the whole mbuf for each packet ?
> 
> The issue that I'm raising is that it's unusual to take an
> uninitialized, indeterminate field, and then initialize it by 
clearing a
> few bits.  It's much more conventional to initialize it by setting it 
to
> zero, like this:
> 
> p->mbuf.ol_flags = 0;
> 
> 
> That is better; I will create a separate function then.
> I will resend
> Thanks
[Sugesh] I also agree with Ben here.
Currently OVS uses only checksum offload flags from mbuf(As I am aware of). 
But there are other flag bits that may get used in future like TSO.
So its better to initialize the mbuf properly before using.

Here is the mbuf reset function in DPDK that get called when an existing 
memory is mapped to 
Mbuf.  
I believe only the ol_flags are relevant for now in OVS.

There is no higher cost associated with initializing all the ol_flags vs some 
flags, so that is fine.
It will be done twice in the case of a packet received from a dpdk device, but 
it is a small cost.
I was more concerned about the dual responsibility conflict when packets are 
received from a DPDK
device and this is why I wanted to limit the scope of the flag management in 
OVS; it should be ok, though.
Hence, I mentioned that I will initialize all the ol_flags.

JTBC, are you suggesting to initialize all the fields below ?
This would mean when packets are received from a DPDK dev, both the rte library 
and OVS
would separately initialize all the fields below – meaning, it would be 

Re: [ovs-dev] [PATCH] python: make python idl unicode-tolerant

2017-08-09 Thread Lance Richardson
> From: "Russell Bryant" 
> To: "Ben Pfaff" 
> Cc: "Lance Richardson" , "ovs dev" 
> Sent: Wednesday, August 9, 2017 3:42:05 PM
> Subject: Re: [ovs-dev] [PATCH] python: make python idl unicode-tolerant
> 
> On Wed, Aug 9, 2017 at 3:32 PM, Ben Pfaff  wrote:
> > On Wed, Aug 09, 2017 at 03:27:32PM -0400, Russell Bryant wrote:
> >> On Tue, Aug 8, 2017 at 2:44 PM, Lance Richardson 
> >> wrote:
> >> > Ensure that JSON is utf-8 encoded and that bytes sent/received on
> >> > the stream sockets are in utf-8 form. Add a test case to verify
> >> > that unicode column data can be sent/received successfully using
> >> > Python module.
> >> >
> >> > JSON encoder magic to ensure utf-8 encoding  suggested by Terry
> >> > Wilson.
> >> >
> >> > Suggested-by: Terry Wilson 
> >> > Signed-off-by: Lance Richardson 
> >> > ---
> >> >  python/ovs/json.py|  9 +++--
> >> >  python/ovs/jsonrpc.py |  3 +--
> >> >  python/ovs/stream.py  |  6 --
> >> >  tests/ovsdb-idl.at| 13 +
> >> >  tests/test-ovsdb.py   |  5 -
> >> >  5 files changed, 29 insertions(+), 7 deletions(-)
> >>
> >> We discussed this patch on IRC, but for the record:
> >>
> >> There's a line in test-ovsdb.py that's too long.  flake8 complained
> >> about it for me.
> >>
> >> The changes to ovsdb-idl.at contain some unicode that my terminal
> >> chokes on.  After spending far too much time trying to figure out why,
> >> I was able to work around it by changing the crazy face to an
> >> appropriate alternative which seems to work OK: (╯°□°)╯︵ ┻━┻
> >
> > Russell, do you want to handle the review for this?  It looks OK to me
> > but it sounds like you have some specific changes to make, so I think
> > you should go for it.
> 
> Yeah, I'll handle this one.  Thanks.
> 
> It looked OK for me other than how it made my terminal crash when I
> tried to view it.  :-)
> 

It must be really good if just looking at it causes coredumps :)

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


Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum flags on init.

2017-08-09 Thread Chandran, Sugesh


Regards
_Sugesh


> > >
> > > Correct, I reused reset_dp_packet_checksum_ol_flags() to do the
> > initialization as well
> > > I could also have created a separate function.
> > >
> > > In case a DPDK dev is used, those flags will be managed by DPDK.
> > >
> > >  That sounds like a
> > > bug in itself--is there a missing call to initialize the mbuf
> somewhere?
> > >
> > > Are you suggesting to initialize the whole mbuf for each packet ?
> >
> > The issue that I'm raising is that it's unusual to take an
> > uninitialized, indeterminate field, and then initialize it by 
> clearing a
> > few bits.  It's much more conventional to initialize it by setting 
> it to
> > zero, like this:
> >
> > p->mbuf.ol_flags = 0;
> >
> >
> > That is better; I will create a separate function then.
> > I will resend
> > Thanks
> [Sugesh] I also agree with Ben here.
> Currently OVS uses only checksum offload flags from mbuf(As I am aware
> of).
> But there are other flag bits that may get used in future like TSO.
> So its better to initialize the mbuf properly before using.
> 
> Here is the mbuf reset function in DPDK that get called when an existing
> memory is mapped to
> Mbuf.
> I believe only the ol_flags are relevant for now in OVS.
> 
> There is no higher cost associated with initializing all the ol_flags vs some
> flags, so that is fine.
> It will be done twice in the case of a packet received from a dpdk device, but
> it is a small cost.
> I was more concerned about the dual responsibility conflict when packets are
> received from a DPDK device and this is why I wanted to limit the scope of
> the flag management in OVS; it should be ok, though.
> Hence, I mentioned that I will initialize all the ol_flags.
> 
> JTBC, are you suggesting to initialize all the fields below ?
> This would mean when packets are received from a DPDK dev, both the rte
> library and OVS would separately initialize all the fields below – meaning, it
> would be done twice for each packet.
> 
[Sugesh] No, we don’t have to initialize all the fields. But we can have a 
generic function
to init all mbuf fields that are relevant in OVS. 
For now its only ol_flags. In the future this function must be updated when we 
use more
fields from rte_mbuf.

Sorry, I really didn’t get the case you mentioned above, where the init get 
called twice.
What I can see in the code is , during the dpdk mp init, the 
the dp_packet_init is called for rte_mbuf initialization. This happens at port 
initiation.

On packet reception, there wont any call to dp_packet_init.


> 
> static inline void rte_pktmbuf_reset(struct rte_mbuf *m)
> {
> m->next = NULL;
> m->pkt_len = 0;
> m->tx_offload = 0;
> m->vlan_tci = 0;
> m->vlan_tci_outer = 0;
> m->nb_segs = 1;
> m->port = 0xff;
> 
> m->ol_flags = 0;
> m->packet_type = 0;
> rte_pktmbuf_reset_headroom(m);
> 
> m->data_len = 0;
> __rte_mbuf_sanity_check(m, 1);
> }
> 
> >
> >
> > That made me wonder whether there's a larger problem of a failure to
> > initialize the mbuf more generally, although of course that does not
> > necessarily follow.
> >
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__mail.openvswitch.org_mailman_listinfo_ovs-
> 2Ddev=DwIFAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-
> uZnsw=wM40bZgtG4Ul1nb53ufLGymPOplaXttP5W6_wL2w_XA=05T6d
> 75pGHINP78-6gwS87E3IhAXzHojsFzyNSDdaTY=
> 

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


Re: [ovs-dev] [PATCH 1/2] ofproto-dpif-ipfix: Use common OVS functions for getting current time.

2017-08-09 Thread Ben Pfaff
On Mon, Aug 07, 2017 at 01:27:37PM -0700, Andy Zhou wrote:
> On Mon, Jun 5, 2017 at 6:04 PM, Ben Pfaff  wrote:
> > OVS has common infrastructure functions for getting the current time, but
> > this code was not using them.  It is not clear why, so this commit changes
> > it to use them.
> >
> > Signed-off-by: Ben Pfaff 
> 
> Acked-by: Andy Zhou 

Thanks, I applied this to master (only).
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH] redhat: add vfio udev rules

2017-08-09 Thread Aaron Conole
This commit builds on the non-root ovs work and adds a udev rule which will
automatically set the group permissions of vfio devices.

Signed-off-by: Aaron Conole 
---
Systemd folks say that this is not something that should be a part of systemd,
but should be part of openvswitch.  I can make a case for either, but it seems
it's probably an uphill battle to get it in through systemd.  This should be
applied on branch-2.8, as it _could_ be considered a "fix" for
commit e3e738a3d058 ("redhat: allow dpdk to also run as non-root user").

 rhel/automake.mk| 1 +
 rhel/openvswitch-fedora.spec.in | 8 
 rhel/usr_lib_udev_rules.d_91-vfio.rules | 1 +
 3 files changed, 10 insertions(+)
 create mode 100644 rhel/usr_lib_udev_rules.d_91-vfio.rules

diff --git a/rhel/automake.mk b/rhel/automake.mk
index 11c8be0..1d1ac1a 100644
--- a/rhel/automake.mk
+++ b/rhel/automake.mk
@@ -26,6 +26,7 @@ EXTRA_DIST += \
rhel/openvswitch-fedora.spec.in \
rhel/usr_share_openvswitch_scripts_sysconfig.template \
rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template \
+   rhel/usr_lib_udev_rules.d_91-vfio.rules \
rhel/usr_lib_systemd_system_openvswitch.service \
rhel/usr_lib_systemd_system_ovsdb-server.service \
rhel/usr_lib_systemd_system_ovs-vswitchd.service.in \
diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in
index 2eccada..59e8ff8 100644
--- a/rhel/openvswitch-fedora.spec.in
+++ b/rhel/openvswitch-fedora.spec.in
@@ -250,6 +250,11 @@ install -d -m 0755 $RPM_BUILD_ROOT%{_rundir}/openvswitch
 install -d -m 0750 $RPM_BUILD_ROOT%{_localstatedir}/log/openvswitch
 install -d -m 0755 $RPM_BUILD_ROOT%{_sysconfdir}/openvswitch
 
+%if %{with dpdk}
+install -p -D -m 0644 rhel/usr_lib_udev_rules.d_91-vfio.rules \
+$RPM_BUILD_ROOT%{_prefix}/lib/udev/rules.d/91-vfio.rules
+%endif
+
 install -p -D -m 0644 \
 rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template \
 $RPM_BUILD_ROOT/%{_sysconfdir}/sysconfig/openvswitch
@@ -566,6 +571,9 @@ fi
 %{_mandir}/man8/ovs-vswitchd.8*
 %{_mandir}/man8/ovs-parse-backtrace.8*
 %{_mandir}/man8/ovs-testcontroller.8*
+%if %{with dpdk}
+%{_prefix}/lib/udev/rules.d/91-vfio.rules
+%endif
 %doc COPYING NOTICE README.rst NEWS rhel/README.RHEL.rst
 /var/lib/openvswitch
 /var/log/openvswitch
diff --git a/rhel/usr_lib_udev_rules.d_91-vfio.rules 
b/rhel/usr_lib_udev_rules.d_91-vfio.rules
new file mode 100644
index 000..8e34b2a
--- /dev/null
+++ b/rhel/usr_lib_udev_rules.d_91-vfio.rules
@@ -0,0 +1 @@
+ACTION=="add", SUBSYSTEM=="vfio*", GROUP="hugetlbfs", MODE="0660"
-- 
2.9.4

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


[ovs-dev] [PATCH 1/3] checkpatch: Check for infix operator whitespace.

2017-08-09 Thread Joe Stringer
The 'Expressions' section of the coding style specifies that one space
should be on either side of infix binary and ternary operators. This
adds a check to checkpatch.py for most of these.

The regex won't match if there are speech marks on the line, because
the style should not apply to the contents of strings.

This check is left at warning level because there isn't a good way to
determine whether a line is within a multiline comment or string, so it
will occasionally flag such lines which contain hyphenated words.

Signed-off-by: Joe Stringer 
---
 utilities/checkpatch.py | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/utilities/checkpatch.py b/utilities/checkpatch.py
index 684c8b201d22..8b9ca0f504d3 100755
--- a/utilities/checkpatch.py
+++ b/utilities/checkpatch.py
@@ -275,6 +275,25 @@ checks += [
 for (function_name, description) in std_functions]
 
 
+def regex_operator_factory(operator):
+regex = re.compile(r'^[^#][^"\']*[^ "]%s[^ "\'][^"]*' % operator)
+return lambda x: regex.search(x) is not None
+
+
+infix_operators = \
+[re.escape(op) for op in ['/', '%', '<<', '>>', '<=', '>=', '==', '!=',
+'^', '|', '&&', '||', '?:', '=', '+=', '-=', '*=', '/=', '%=',
+'&=', '^=', '|=', '<<=', '>>=']] \
++ ['[^<" ]<[^=" ]', '[^->" ]>[^=" ]', '[^ !()/"]\*[^/]', '[^ !&()"]&',
+   '[^" +(]\+[^"+;]', '[^" -(]-[^"->;]', '[^" <>=!^|+\-*/%&]=[^"=]']
+checks += [
+{'regex': '(\.c|\.h)(\.in)?$', 'match_name': None,
+ 'prereq': lambda x: not is_comment_line(x),
+ 'check': regex_operator_factory(operator),
+ 'print': lambda: print_warning("Line lacks whitespace around operator")}
+for operator in infix_operators]
+
+
 def get_file_type_checks(filename):
 """Returns the list of checks for a file based on matching the filename
against regex."""
-- 
2.13.3

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


Re: [ovs-dev] ovsdb-server replication: Possible to exclude syncing specific column of a table??

2017-08-09 Thread Ben Pfaff
On Wed, Aug 09, 2017 at 05:34:16PM +0530, Arunkumar Rg wrote:
> Hi All,
> 
> I need a clarification on ovsdb-server replication's
> set-sync-exclude-tables.
> 
> *Is there a way, by which we can say exclude syncing specific column of a
> table??*
> 
> The use case I'm looking at is:
> 
>1. The replication is configured for DB "hardware_vtep".
>2. I'm trying to use the "ovsdb-server/set-sync-exclude-tables" unixctl
>command for table "hardware_vtep:Manager" on the backup ovsdb-server.
>3. After this the backup ovsdb-server gets replica(notification) from
>the active's db except for 'Manager' table.
>4. At this poiint, while processing the notification for 'Global' table,
>I see the below error:
>5. "Aug  9 12:26:38 Pollux daemon.err ovsdb-server:
>ovs|00070|ovsdb_error|ERR|unexpected ovsdb error: referential integrity
>violation: Table Global column managers row
>4121ba6c-a729-45b1-8f69-806b32584d04 references nonexistent row
>5dbedec1-8221-435f-89b3-503867d0e987 in t""
>6. I think this error could be avoided if we can say exclude syncing
>'Manager' column in 'Global' table also.

It sounds like a bug.  Probably, you should report the bug and get it
fixed, instead of trying to work around it.

How can we reproduce the bug?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH v4 2/6] dpif-netdev: Add rxq processing cycle counters.

2017-08-09 Thread Kevin Traynor
Add two counters to dp_netdev_rxq which will be used for storing the
processing cycles of an rxq. Processing cycles will be stored in reference
to a defined interval. One counter is used for storing cycles during the
current in progress interval, while the other is used to store the cycles
of the last fully complete interval.

cycles_count_intermediate was used to count cycles for a pmd. With some small
additions we can also use it to count the cycles used for processing an rxq.

Signed-off-by: Kevin Traynor 
---
 lib/dpif-netdev.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index f35c079..41f16b2 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -340,4 +340,11 @@ enum pmd_cycles_counter_type {
 };
 
+enum rxq_cycles_counter_type {
+RXQ_CYCLES_PROC_CURR,  /* Cycles spent successfully polling and
+  processing polled packets */
+RXQ_CYCLES_PROC_LAST,
+RXQ_N_CYCLES
+};
+
 #define XPS_TIMEOUT_MS 500LL
 
@@ -351,4 +358,5 @@ struct dp_netdev_rxq {
   particular core. */
 struct dp_netdev_pmd_thread *pmd;  /* pmd thread that polls this queue. */
+atomic_ullong cycles[RXQ_N_CYCLES];
 };
 
@@ -677,5 +685,4 @@ static void pmd_load_cached_ports(struct 
dp_netdev_pmd_thread *pmd)
 static inline void
 dp_netdev_pmd_try_optimize(struct dp_netdev_pmd_thread *pmd);
-
 static void
 dpif_netdev_xps_revalidate_pmd(const struct dp_netdev_pmd_thread *pmd,
@@ -3092,4 +3099,5 @@ cycles_count_end(struct dp_netdev_pmd_thread *pmd,
 static inline void
 cycles_count_intermediate(struct dp_netdev_pmd_thread *pmd,
+  struct dp_netdev_rxq *rxq,
   enum pmd_cycles_counter_type type)
 OVS_NO_THREAD_SAFETY_ANALYSIS
@@ -3100,4 +3108,8 @@ cycles_count_intermediate(struct dp_netdev_pmd_thread 
*pmd,
 
 non_atomic_ullong_add(>cycles.n[type], interval);
+if (rxq && (type == PMD_CYCLES_PROCESSING)) {
+/* Add to the amount of current processing cycles. */
+non_atomic_ullong_add(>cycles[RXQ_CYCLES_PROC_CURR], interval);
+}
 }
 
@@ -3668,5 +3680,5 @@ dpif_netdev_run(struct dpif *dpif)
port->rxqs[i].rx,
port->port_no);
-cycles_count_intermediate(non_pmd, process_packets ?
+cycles_count_intermediate(non_pmd, NULL, process_packets ?
PMD_CYCLES_PROCESSING
  : PMD_CYCLES_IDLE);
@@ -3855,5 +3867,5 @@ reload:
 dp_netdev_process_rxq_port(pmd, poll_list[i].rxq->rx,
poll_list[i].port_no);
-cycles_count_intermediate(pmd,
+cycles_count_intermediate(pmd, NULL,
   process_packets ? PMD_CYCLES_PROCESSING
   : PMD_CYCLES_IDLE);
-- 
1.8.3.1

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


[ovs-dev] [PATCH v4 3/6] dpif-netdev: Count the rxq processing cycles for an rxq.

2017-08-09 Thread Kevin Traynor
Count the cycles used for processing an rxq during the
pmd rxq interval. As this is an in flight counter and
pmds run independently, also store the total cycles used
during the last full interval.

Signed-off-by: Kevin Traynor 
---
 lib/dpif-netdev.c | 65 ++-
 1 file changed, 60 insertions(+), 5 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 41f16b2..e344063 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -182,4 +182,8 @@ struct emc_cache {
 #define DPCLS_OPTIMIZATION_INTERVAL 1000
 
+/* Time in ms of the interval in which rxq processing cycles used in
+ * rxq to pmd assignments is measured and stored. */
+#define PMD_RXQ_INTERVAL 1000
+
 struct dpcls {
 struct cmap_node node;  /* Within dp_netdev_pmd_thread.classifiers */
@@ -558,4 +562,6 @@ struct dp_netdev_pmd_thread {
 /* Periodically sort subtable vectors according to hit frequencies */
 long long int next_optimization;
+/* Periodically store the processing cycles used for each rxq. */
+long long int rxq_interval;
 
 /* Statistics. */
@@ -684,5 +690,13 @@ static void pmd_load_cached_ports(struct 
dp_netdev_pmd_thread *pmd)
 OVS_REQUIRES(pmd->port_mutex);
 static inline void
-dp_netdev_pmd_try_optimize(struct dp_netdev_pmd_thread *pmd);
+dp_netdev_pmd_try_optimize(struct dp_netdev_pmd_thread *pmd,
+   struct polled_queue *poll_list, int poll_cnt);
+static void
+dp_netdev_rxq_set_cycles(struct dp_netdev_rxq *rx,
+ enum rxq_cycles_counter_type type,
+ unsigned long long cycles);
+static uint64_t
+dp_netdev_rxq_get_cycles(struct dp_netdev_rxq *rx,
+ enum rxq_cycles_counter_type type);
 static void
 dpif_netdev_xps_revalidate_pmd(const struct dp_netdev_pmd_thread *pmd,
@@ -3114,4 +3128,21 @@ cycles_count_intermediate(struct dp_netdev_pmd_thread 
*pmd,
 }
 
+static void
+dp_netdev_rxq_set_cycles(struct dp_netdev_rxq *rx,
+ enum rxq_cycles_counter_type type,
+ unsigned long long cycles)
+{
+   atomic_store_relaxed(>cycles[type], cycles);
+}
+
+static uint64_t
+dp_netdev_rxq_get_cycles(struct dp_netdev_rxq *rx,
+ enum rxq_cycles_counter_type type)
+{
+unsigned long long tmp;
+atomic_read_relaxed(>cycles[type], );
+return tmp;
+}
+
 static int
 dp_netdev_process_rxq_port(struct dp_netdev_pmd_thread *pmd,
@@ -3158,5 +3189,5 @@ port_reconfigure(struct dp_netdev_port *port)
 {
 struct netdev *netdev = port->netdev;
-int i, err;
+int i, err, last_nrxq;
 
 port->need_reconfigure = false;
@@ -3167,4 +3198,5 @@ port_reconfigure(struct dp_netdev_port *port)
 port->rxqs[i].rx = NULL;
 }
+last_nrxq = port->n_rxq;
 port->n_rxq = 0;
 
@@ -3187,4 +3219,9 @@ port_reconfigure(struct dp_netdev_port *port)
 for (i = 0; i < netdev_n_rxq(netdev); i++) {
 port->rxqs[i].port = port;
+if (i >= last_nrxq) {
+/* Only reset cycle stats for new queues */
+dp_netdev_rxq_set_cycles(>rxqs[i], RXQ_CYCLES_PROC_CURR, 0);
+dp_netdev_rxq_set_cycles(>rxqs[i], RXQ_CYCLES_PROC_LAST, 0);
+}
 err = netdev_rxq_open(netdev, >rxqs[i].rx, i);
 if (err) {
@@ -3867,5 +3904,5 @@ reload:
 dp_netdev_process_rxq_port(pmd, poll_list[i].rxq->rx,
poll_list[i].port_no);
-cycles_count_intermediate(pmd, NULL,
+cycles_count_intermediate(pmd, poll_list[i].rxq,
   process_packets ? PMD_CYCLES_PROCESSING
   : PMD_CYCLES_IDLE);
@@ -3878,5 +3915,5 @@ reload:
 
 coverage_try_clear();
-dp_netdev_pmd_try_optimize(pmd);
+dp_netdev_pmd_try_optimize(pmd, poll_list, poll_cnt);
 if (!ovsrcu_try_quiesce()) {
 emc_cache_slow_sweep(>flow_cache);
@@ -4322,4 +4359,5 @@ dp_netdev_configure_pmd(struct dp_netdev_pmd_thread *pmd, 
struct dp_netdev *dp,
 cmap_init(>classifiers);
 pmd->next_optimization = time_msec() + DPCLS_OPTIMIZATION_INTERVAL;
+pmd->rxq_interval = time_msec() + PMD_RXQ_INTERVAL;
 hmap_init(>poll_list);
 hmap_init(>tx_ports);
@@ -5759,8 +5797,25 @@ dpcls_sort_subtable_vector(struct dpcls *cls)
 
 static inline void
-dp_netdev_pmd_try_optimize(struct dp_netdev_pmd_thread *pmd)
+dp_netdev_pmd_try_optimize(struct dp_netdev_pmd_thread *pmd,
+   struct polled_queue *poll_list, int poll_cnt)
 {
 struct dpcls *cls;
 long long int now = time_msec();
+int i;
+uint64_t rxq_cyc_curr;
+
+if (now > pmd->rxq_interval) {
+/* Get the cycles that were used to process each queue and store. */
+for (i = 0; i < poll_cnt; i++) {
+rxq_cyc_curr = dp_netdev_rxq_get_cycles(poll_list[i].rxq,
+   

Re: [ovs-dev] [PATCH] ovn-northd: Add native active-standby HA.

2017-08-09 Thread Ben Pfaff
On Tue, Aug 01, 2017 at 12:19:18PM -0400, Russell Bryant wrote:
> Add native support for active-standby HA in ovn-northd by having each
> instance attempt to acquire an OVSDB lock.  Only the instance of
> ovn-northd that currently holds the lock will make active changes to
> the OVN databases.
> 
> Signed-off-by: Russell Bryant 
> ---
>  NEWS|  1 +
>  ovn/northd/ovn-northd.8.xml |  9 +
>  ovn/northd/ovn-northd.c | 40 +++-
>  3 files changed, 41 insertions(+), 9 deletions(-)
> 
> diff --git a/NEWS b/NEWS
> index facea0228..f3cdd2443 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -49,6 +49,7 @@ Post-v2.7.0
> one chassis is specified, OVN will manage high availability for that
> gateway.
>   * Add support for ACL logging.
> + * ovn-northd now has native support for active-standby high 
> availability.
> - Tracing with ofproto/trace now traces through recirculation.
> - OVSDB:
>   * New support for role-based access control (see ovsdb-server(1)).

Are you trying to still get this into 2.8.0?  If not, then this should
move to the new post-v2.8.0 section.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH v4 4/6] dpif-netdev: Change rxq_scheduling to use rxq processing cycles.

2017-08-09 Thread Kevin Traynor
Previously rxqs were assigned to pmds by round robin in
port/queue order.

Now that we have the processing cycles used for existing rxqs,
use that information to try and produced a better balanced
distribution of rxqs across pmds. i.e. given multiple pmds, the
rxqs which have consumed the largest amount of processing cycles
will be placed on different pmds.

The rxqs are sorted by their processing cycles and assigned (in
sorted order) round robin across pmds.

Signed-off-by: Kevin Traynor 
---
 Documentation/howto/dpdk.rst |   7 +++
 lib/dpif-netdev.c| 105 ++-
 2 files changed, 81 insertions(+), 31 deletions(-)

diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index d7f6610..44737e4 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -119,4 +119,11 @@ After that PMD threads on cores where RX queues was pinned 
will become
   thread.
 
+If pmd-rxq-affinity is not set for rxqs, they will be assigned to pmds (cores)
+automatically. The processing cycles that have been required for each rxq
+will be used where known to assign rxqs with the highest consumption of
+processing cycles to different pmds.
+
+Rxq to pmds assignment takes place whenever there are configuration changes.
+
 QoS
 ---
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index e344063..b4663ab 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -3328,8 +3328,29 @@ rr_numa_list_destroy(struct rr_numa_list *rr)
 }
 
+/* Sort Rx Queues by the processing cycles they are consuming. */
+static int
+rxq_cycle_sort(const void *a, const void *b)
+{
+struct dp_netdev_rxq * qa;
+struct dp_netdev_rxq * qb;
+
+qa = *(struct dp_netdev_rxq **) a;
+qb = *(struct dp_netdev_rxq **) b;
+
+if (dp_netdev_rxq_get_cycles(qa, RXQ_CYCLES_PROC_LAST) >=
+dp_netdev_rxq_get_cycles(qb, RXQ_CYCLES_PROC_LAST)) {
+return -1;
+}
+
+return 1;
+}
+
 /* Assign pmds to queues.  If 'pinned' is true, assign pmds to pinned
  * queues and marks the pmds as isolated.  Otherwise, assign non isolated
  * pmds to unpinned queues.
  *
+ * If 'pinned' is false queues will be sorted by processing cycles they are
+ * consuming and then assigned to pmds in round robin order.
+ *
  * The function doesn't touch the pmd threads, it just stores the assignment
  * in the 'pmd' member of each rxq. */
@@ -3340,18 +3361,14 @@ rxq_scheduling(struct dp_netdev *dp, bool pinned) 
OVS_REQUIRES(dp->port_mutex)
 struct rr_numa_list rr;
 struct rr_numa *non_local_numa = NULL;
-
-rr_numa_list_populate(dp, );
+struct dp_netdev_rxq ** rxqs = NULL;
+int i, n_rxqs = 0;
+struct rr_numa *numa = NULL;
+int numa_id;
 
 HMAP_FOR_EACH (port, node, >ports) {
-struct rr_numa *numa;
-int numa_id;
-
 if (!netdev_is_pmd(port->netdev)) {
 continue;
 }
 
-numa_id = netdev_get_numa_id(port->netdev);
-numa = rr_numa_list_lookup(, numa_id);
-
 for (int qid = 0; qid < port->n_rxq; qid++) {
 struct dp_netdev_rxq *q = >rxqs[qid];
@@ -3371,34 +3388,60 @@ rxq_scheduling(struct dp_netdev *dp, bool pinned) 
OVS_REQUIRES(dp->port_mutex)
 }
 } else if (!pinned && q->core_id == OVS_CORE_UNSPEC) {
-if (!numa) {
-/* There are no pmds on the queue's local NUMA node.
-   Round-robin on the NUMA nodes that do have pmds. */
-non_local_numa = rr_numa_list_next(, non_local_numa);
-if (!non_local_numa) {
-VLOG_ERR("There is no available (non-isolated) pmd "
- "thread for port \'%s\' queue %d. This queue "
- "will not be polled. Is pmd-cpu-mask set to "
- "zero? Or are all PMDs isolated to other "
- "queues?", netdev_get_name(port->netdev),
- qid);
-continue;
-}
-q->pmd = rr_numa_get_pmd(non_local_numa);
-VLOG_WARN("There's no available (non-isolated) pmd thread "
-  "on numa node %d. Queue %d on port \'%s\' will "
-  "be assigned to the pmd on core %d "
-  "(numa node %d). Expect reduced performance.",
-  numa_id, qid, netdev_get_name(port->netdev),
-  q->pmd->core_id, q->pmd->numa_id);
+if (n_rxqs == 0) {
+rxqs = xmalloc(sizeof *rxqs);
 } else {
-/* Assign queue to the next (round-robin) PMD on it's local
-   NUMA node. */
-q->pmd = rr_numa_get_pmd(numa);
+rxqs = xrealloc(rxqs, sizeof *rxqs * (n_rxqs + 1));
 

Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum flags on init.

2017-08-09 Thread Darrell Ball


-Original Message-
From:  on behalf of Ben Pfaff 
Date: Wednesday, August 9, 2017 at 10:15 AM
To: Darrell Ball 
Cc: "d...@openvswitch.org" 
Subject: Re: [ovs-dev] [patch_v5] dp-packet: Reset DPDK HWOL checksum flags on 
init.

On Tue, Aug 08, 2017 at 06:54:46PM -0700, Darrell Ball wrote:
> Reset the DPDK HWOL checksum flags in dp_packet_init_.
> The new HWOL bad checksum flag is uninitialized for non-dpdk ports and
> this is noticed as test failures using netdev-dummy ports, when built with
> the --with-dpdk flag set. Hence, in this case, packets may be marked as
> having a bad checksum.
> 
> Reported-at: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddiscuss_2017-2DAugust_045081.html=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=EgRiug3JzTWpaX_uPPtj_OgcJSFiS2u3wJ7Ai4zOFco=oy4i6VCzrCZUvKM_MTyTuBfs3Rr5bpEMYLUrf8U5xJ8=
 
> Fixes: 7451af618e0d ("dp-packet : Update DPDK rx checksum validation 
functions.")
> CC: Sugesh Chandran 
> Signed-off-by: Darrell Ball 
> ---
> 
> v3->v5: Update the commit message with more context.
> 
> v2->v3: Use existed API to reset both the DPDK HWOL flags.
> 
> v1->v2: Fix build failure for without --with-dpdk.
> 
>  lib/dp-packet.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/dp-packet.c b/lib/dp-packet.c
> index 67aa406..4926993 100644
> --- a/lib/dp-packet.c
> +++ b/lib/dp-packet.c
> @@ -31,6 +31,7 @@ dp_packet_init__(struct dp_packet *b, size_t allocated, 
enum dp_packet_source so
>  dp_packet_reset_offsets(b);
>  pkt_metadata_init(>md, 0);
>  dp_packet_rss_invalidate(b);
> +reset_dp_packet_checksum_ol_flags(b);

This function un-sets some bits in p->mbuf.ol_flags.  The need for this
implies that nothing initializes p->mbuf.ol_flags. 

Correct, I reused reset_dp_packet_checksum_ol_flags() to do the initialization 
as well
I could also have created a separate function.

In case a DPDK dev is used, those flags will be managed by DPDK.


 That sounds like a
bug in itself--is there a missing call to initialize the mbuf somewhere?

Are you suggesting to initialize the whole mbuf for each packet ?


___
dev mailing list
d...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=EgRiug3JzTWpaX_uPPtj_OgcJSFiS2u3wJ7Ai4zOFco=8LpUtCrGVDRQM5ZWlDCmesUD03YK0LwIgc2o6NsJ-0Y=
 


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


[ovs-dev] [PATCH v4 5/6] dpif-netdev: Change pmd selection order.

2017-08-09 Thread Kevin Traynor
Up to his point rxqs are sorted by processing cycles they
consumed and assigned to pmds in a round robin manner.

Ian pointed out that on wrap around the most loaded pmd will be
the next one to be assigned an additional rxq and that it would be
better to reverse the pmd order when wraparound occurs.

In other words, change from assigning by rr to assigning in a forward
and reverse cycle through pmds.

Also, now that the algothim has finalised, document an example.

Suggested-by: Ian Stokes 
Signed-off-by: Kevin Traynor 
---
 Documentation/howto/dpdk.rst | 16 
 lib/dpif-netdev.c| 21 -
 tests/pmd.at |  2 +-
 3 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index 44737e4..493e215 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -124,4 +124,20 @@ will be used where known to assign rxqs with the highest 
consumption of
 processing cycles to different pmds.
 
+For example, in the case where here there are 5 rxqs and 3 cores (e.g. 3,7,8)
+available, and the measured usage of core cycles per rxq over the last
+interval is seen to be:
+
+- Queue #0: 30%
+- Queue #1: 80%
+- Queue #3: 60%
+- Queue #4: 70%
+- Queue #5: 10%
+
+The rxqs will be assigned to cores 3,7,8 in the following order:
+
+Core 3: Q1 (80%) |
+Core 7: Q4 (70%) | Q5 (10%)
+core 8: Q0 (60%) | Q0 (30%)
+
 Rxq to pmds assignment takes place whenever there are configuration changes.
 
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index b4663ab..b0f4010 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -3251,4 +3251,5 @@ struct rr_numa {
 
 int cur_index;
+bool idx_inc;
 };
 
@@ -3307,4 +3308,7 @@ rr_numa_list_populate(struct dp_netdev *dp, struct 
rr_numa_list *rr)
 numa->pmds = xrealloc(numa->pmds, numa->n_pmds * sizeof *numa->pmds);
 numa->pmds[numa->n_pmds - 1] = pmd;
+/* At least one pmd so initialise curr_idx and idx_inc. */
+numa->cur_index = 0;
+numa->idx_inc = true;
 }
 }
@@ -3313,5 +3317,20 @@ static struct dp_netdev_pmd_thread *
 rr_numa_get_pmd(struct rr_numa *numa)
 {
-return numa->pmds[numa->cur_index++ % numa->n_pmds];
+int numa_idx = numa->cur_index;
+
+if (numa->idx_inc == true) {
+if (numa->cur_index == numa->n_pmds-1) {
+numa->idx_inc = false;
+} else {
+numa->cur_index++;
+}
+} else {
+if (numa->cur_index == 0) {
+numa->idx_inc = true;
+} else {
+numa->cur_index--;
+}
+}
+return numa->pmds[numa_idx];
 }
 
diff --git a/tests/pmd.at b/tests/pmd.at
index b6732ea..e39a23a 100644
--- a/tests/pmd.at
+++ b/tests/pmd.at
@@ -54,5 +54,5 @@ m4_define([CHECK_PMD_THREADS_CREATED], [
 
 m4_define([SED_NUMA_CORE_PATTERN], ["s/\(numa_id \)[[0-9]]*\( core_id 
\)[[0-9]]*:/\1\2:/"])
-m4_define([SED_NUMA_CORE_QUEUE_PATTERN], ["s/\(numa_id \)[[0-9]]*\( core_id 
\)[[0-9]]*:/\1\2:/;s/\(queue-id: \)0 2 4 
6/\1/;s/\(queue-id: \)1 3 5 7/\1/"])
+m4_define([SED_NUMA_CORE_QUEUE_PATTERN], ["s/\(numa_id \)[[0-9]]*\( core_id 
\)[[0-9]]*:/\1\2:/;s/\(queue-id: \)1 2 5 
6/\1/;s/\(queue-id: \)0 3 4 7/\1/"])
 m4_define([DUMMY_NUMA], [--dummy-numa="0,0,0,0"])
 
-- 
1.8.3.1

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


[ovs-dev] [PATCH v4 6/6] dpif-netdev: Add ovs-appctl dpif-netdev/pmd-rxq-rebalance.

2017-08-09 Thread Kevin Traynor
Rxqs consumed processing cycles are used to improve the balance
of how rxqs are assigned to pmds. Currently some reconfiguration
is needed to perform a reassignment.

Add an ovs-appctl command to perform a new assignment in order
to balance based on the latest rxq processing cycle information.

Note: Jan requested this for testing purposes.

Suggested-by: Jan Scheurich 
Signed-off-by: Kevin Traynor 
---
 Documentation/howto/dpdk.rst |  5 -
 lib/dpif-netdev.c| 35 +++
 vswitchd/ovs-vswitchd.8.in   |  2 ++
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index 493e215..5d009bd 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -140,5 +140,8 @@ Core 7: Q4 (70%) | Q5 (10%)
 core 8: Q0 (60%) | Q0 (30%)
 
-Rxq to pmds assignment takes place whenever there are configuration changes.
+Rxq to pmds assignment takes place whenever there are configuration changes
+or can be triggered by using::
+
+$ ovs-appctl dpif-netdev/pmd-rxq-rebalance
 
 QoS
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index b0f4010..8857489 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -708,4 +708,6 @@ static inline bool emc_entry_alive(struct emc_entry *ce);
 static void emc_clear_entry(struct emc_entry *ce);
 
+static void dp_netdev_request_reconfigure(struct dp_netdev *dp);
+
 static void
 emc_cache_init(struct emc_cache *flow_cache)
@@ -1001,4 +1003,34 @@ sorted_poll_thread_list(struct dp_netdev *dp,
 
 static void
+dpif_netdev_pmd_rebalance(struct unixctl_conn *conn, int argc,
+  const char *argv[], void *aux OVS_UNUSED)
+{
+struct ds reply = DS_EMPTY_INITIALIZER;
+struct dp_netdev *dp = NULL;
+
+ovs_mutex_lock(_netdev_mutex);
+
+if (argc == 2) {
+dp = shash_find_data(_netdevs, argv[1]);
+} else if (shash_count(_netdevs) == 1) {
+/* There's only one datapath */
+dp = shash_first(_netdevs)->data;
+}
+
+if (!dp) {
+ovs_mutex_unlock(_netdev_mutex);
+unixctl_command_reply_error(conn,
+"please specify an existing datapath");
+return;
+}
+
+dp_netdev_request_reconfigure(dp);
+ovs_mutex_unlock(_netdev_mutex);
+ds_put_cstr(, "pmd rxq rebalance requested.\n");
+unixctl_command_reply(conn, ds_cstr());
+ds_destroy();
+}
+
+static void
 dpif_netdev_pmd_info(struct unixctl_conn *conn, int argc, const char *argv[],
  void *aux)
@@ -1078,4 +1110,7 @@ dpif_netdev_init(void)
  0, 1, dpif_netdev_pmd_info,
  (void *)_aux);
+unixctl_command_register("dpif-netdev/pmd-rxq-rebalance", "[dp]",
+ 0, 1, dpif_netdev_pmd_rebalance,
+ NULL);
 return 0;
 }
diff --git a/vswitchd/ovs-vswitchd.8.in b/vswitchd/ovs-vswitchd.8.in
index dfd209e..c18baf6 100644
--- a/vswitchd/ovs-vswitchd.8.in
+++ b/vswitchd/ovs-vswitchd.8.in
@@ -281,4 +281,6 @@ bridge statistics, only the values shown by the above 
command.
 For each pmd thread of the datapath \fIdp\fR shows list of queue-ids with
 port names, which this thread polls.
+.IP "\fBdpif-netdev/pmd-rxq-rebalance\fR [\fIdp\fR]"
+Reassigns rxqs to pmds in the datapath \fIdp\fR based on their current usage.
 .
 .so ofproto/ofproto-dpif-unixctl.man
-- 
1.8.3.1

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


Re: [ovs-dev] Why my AT_CHECK() can't work?

2017-08-09 Thread Ben Pfaff
On Wed, Aug 09, 2017 at 05:23:20PM +0800, Sam wrote:
> Hi all,
> 
> I'm using autotest to test ovs, and I write a new *.at file using only one
> AT_CHECK sentence like this:
> 
> AT_CHECK([ovs-appctl dpdk/bond-show dpdkb2], [0], [stdout])
> > AT_CHECK([[sed '/ACTIVE/p' stdout | head -4]], [0], [[LACP actor_state
> > ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> >  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> > LACP actor_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING
> >  partner_state ACTIVE AGGREGATION SYNC COLLECTING DISTRIBUTING]])
> 

I think you forgot -n in your sed command.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [patch_v1] travis: Fix DPDK builds in new environment.

2017-08-09 Thread Ben Pfaff
On Tue, Aug 08, 2017 at 11:57:36PM -0700, Darrell Ball wrote:
> The following error is seen:
> 17.05.1/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.c:29:
> /home/travis/build/darball/ovs/linux-3.16.46/arch/x86/include/asm/
> dma-mapping.h:32:35: error: inlining failed in call to ‘get_dma_ops’:
> call is unlikely and code size would grow [-Werror=inline]
> 
> -Wno-error=inline is used to address the issues with
> the new environment.
> 
> Suggested-by: Ben Pfaff 
> Signed-off-by: Darrell Ball 

Thanks, applied to master and branch-2.8.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 1/2] travis: Explicitly disable LLVM for sparse build.

2017-08-09 Thread Lance Richardson
> From: "Ben Pfaff" 
> To: "Lance Richardson" 
> Cc: d...@openvswitch.org
> Sent: Wednesday, August 9, 2017 4:47:49 PM
> Subject: Re: [ovs-dev] [PATCH 1/2] travis: Explicitly disable LLVM for sparse 
> build.
> 
> On Wed, Aug 09, 2017 at 04:36:42PM -0400, Lance Richardson wrote:
> > > From: "Ben Pfaff" 
> > > To: d...@openvswitch.org
> > > Cc: "Ben Pfaff" 
> > > Sent: Thursday, July 27, 2017 4:41:05 PM
> > > Subject: [ovs-dev] [PATCH 1/2] travis: Explicitly disable LLVM for sparse
> > >   build.
> > > 
> > > Newer travis environments claim to have LLVM support (llvm-config exists
> > > and works) but in reality don't, which prevents sparse from building and
> > > later parts of the build from succeeding.
> > > 
> > > Signed-off-by: Ben Pfaff 
> > > ---
> > 
> > I don't know what the symptom of this failure was, but some branch-2.6 and
> > branch-2.7
> > travis builds are failing with:
> > 
> >env: cgcc: No such file or directory
> > 
> > Should this be back-ported to other branches?
> 
> Thanks for the note.  Done.
> 

Thanks... I also noticed that the 2.8 and master builds are failing with "The 
job
exceeded the maximum time limit for jobs, and has been terminated." I wonder if
something like "TESTSUITEFLAGS=-j2" would be sufficient to get around this, or 
if
there's a deeper problem that needs to be solved. (I'm assuming there's enough
sleeping/waiting in the tests that this would reduce overall runtime even if 
it's
only a single-core machine...)

Regards,

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


[ovs-dev] [PATCHv2 1/4] ovsdb-idl: Avoid class declaration.

2017-08-09 Thread Joe Stringer
In C++, 'class' is a keyword. If this is used as the name for a field,
then C++ compilers can get confused about the context and fail to
compile references to such fields. Rename the field to 'class_' to
avoid this issue.

Signed-off-by: Joe Stringer 
---
v2: Rebase.
---
 lib/db-ctl-base.c|   4 +-
 lib/ovsdb-idl-provider.h |   2 +-
 lib/ovsdb-idl.c  | 154 +++
 3 files changed, 80 insertions(+), 80 deletions(-)

diff --git a/lib/db-ctl-base.c b/lib/db-ctl-base.c
index d597c6c2af6f..9fec6fa0d59e 100644
--- a/lib/db-ctl-base.c
+++ b/lib/db-ctl-base.c
@@ -635,7 +635,7 @@ check_mutable(const struct ovsdb_idl_row *row,
 {
 if (!ovsdb_idl_is_mutable(row, column)) {
 ctl_fatal("cannot modify read-only column %s in table %s",
-  column->name, row->table->class->name);
+  column->name, row->table->class_->name);
 }
 }
 
@@ -1715,7 +1715,7 @@ cmd_show_find_table_by_row(const struct ovsdb_idl_row 
*row)
 const struct cmd_show_table *show;
 
 for (show = cmd_show_tables; show->table; show++) {
-if (show->table == row->table->class) {
+if (show->table == row->table->class_) {
 return show;
 }
 }
diff --git a/lib/ovsdb-idl-provider.h b/lib/ovsdb-idl-provider.h
index 59fb24015904..a2eb8cac67d7 100644
--- a/lib/ovsdb-idl-provider.h
+++ b/lib/ovsdb-idl-provider.h
@@ -104,7 +104,7 @@ struct ovsdb_idl_table_class {
 };
 
 struct ovsdb_idl_table {
-const struct ovsdb_idl_table_class *class;
+const struct ovsdb_idl_table_class *class_;
 unsigned char *modes;/* OVSDB_IDL_* bitmasks, indexed by column. */
 bool need_table; /* Monitor table even if no columns are selected
   * for replication. */
diff --git a/lib/ovsdb-idl.c b/lib/ovsdb-idl.c
index e916e940b652..227aa5fbfcb2 100644
--- a/lib/ovsdb-idl.c
+++ b/lib/ovsdb-idl.c
@@ -89,11 +89,11 @@ enum ovsdb_idl_state {
 };
 
 struct ovsdb_idl {
-const struct ovsdb_idl_class *class;
+const struct ovsdb_idl_class *class_;
 struct jsonrpc_session *session;
 struct uuid uuid;
 struct shash table_by_name; /* Contains "struct ovsdb_idl_table *"s.*/
-struct ovsdb_idl_table *tables; /* Array of ->class->n_tables elements. */
+struct ovsdb_idl_table *tables; /* Array of ->class_->n_tables elements. */
 unsigned int change_seqno;
 bool verify_write_only;
 
@@ -270,7 +270,7 @@ ovsdb_idl_create(const char *remote, const struct 
ovsdb_idl_class *class,
 : 0);
 
 idl = xzalloc(sizeof *idl);
-idl->class = class;
+idl->class_ = class;
 idl->session = jsonrpc_session_open(remote, retry);
 shash_init(>table_by_name);
 idl->tables = xmalloc(class->n_tables * sizeof *idl->tables);
@@ -280,7 +280,7 @@ ovsdb_idl_create(const char *remote, const struct 
ovsdb_idl_class *class,
 size_t j;
 
 shash_add_assert(>table_by_name, tc->name, table);
-table->class = tc;
+table->class_ = tc;
 table->modes = xmalloc(tc->n_columns);
 memset(table->modes, default_mode, tc->n_columns);
 table->need_table = false;
@@ -338,7 +338,7 @@ ovsdb_idl_destroy(struct ovsdb_idl *idl)
 ovsdb_idl_clear(idl);
 jsonrpc_session_close(idl->session);
 
-for (i = 0; i < idl->class->n_tables; i++) {
+for (i = 0; i < idl->class_->n_tables; i++) {
 struct ovsdb_idl_table *table = >tables[i];
 ovsdb_idl_condition_destroy(>condition);
 ovsdb_idl_destroy_indexes(table);
@@ -363,7 +363,7 @@ ovsdb_idl_clear(struct ovsdb_idl *idl)
 bool changed = false;
 size_t i;
 
-for (i = 0; i < idl->class->n_tables; i++) {
+for (i = 0; i < idl->class_->n_tables; i++) {
 struct ovsdb_idl_table *table = >tables[i];
 struct ovsdb_idl_row *row, *next_row;
 
@@ -768,9 +768,9 @@ ovsdb_idl_check_consistency(const struct ovsdb_idl *idl)
 struct uuid *dsts = NULL;
 size_t allocated_dsts = 0;
 
-for (size_t i = 0; i < idl->class->n_tables; i++) {
+for (size_t i = 0; i < idl->class_->n_tables; i++) {
 const struct ovsdb_idl_table *table = >tables[i];
-const struct ovsdb_idl_table_class *class = table->class;
+const struct ovsdb_idl_table_class *class = table->class_;
 
 const struct ovsdb_idl_row *row;
 HMAP_FOR_EACH (row, hmap_node, >rows) {
@@ -794,16 +794,16 @@ ovsdb_idl_check_consistency(const struct ovsdb_idl *idl)
 dsts, _dsts)) {
 VLOG_ERR("unexpected arc from %s row "UUID_FMT" to %s "
  "row "UUID_FMT,
- table->class->name,
+ table->class_->name,
  UUID_ARGS(>uuid),
- arc->dst->table->class->name,
+ 

[ovs-dev] [PATCHv2 2/4] ovsdb-idl: Avoid mutable type specifier.

2017-08-09 Thread Joe Stringer
In C++, 'mutable' is a keyword. If this is used as the name for a field,
then C++ compilers can get confused about the context and fail to
compile references to such fields. Rename the field to 'mutable_' to
avoid this issue.

Signed-off-by: Joe Stringer 
---
v2: Rebase.
---
 lib/ovsdb-idl-provider.h | 2 +-
 lib/ovsdb-idl.c  | 2 +-
 ovsdb/ovsdb-idlc.in  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/ovsdb-idl-provider.h b/lib/ovsdb-idl-provider.h
index a2eb8cac67d7..aa1fa9390572 100644
--- a/lib/ovsdb-idl-provider.h
+++ b/lib/ovsdb-idl-provider.h
@@ -89,7 +89,7 @@ struct ovsdb_idl_row {
 struct ovsdb_idl_column {
 char *name;
 struct ovsdb_type type;
-bool mutable;
+bool mutable_;
 void (*parse)(struct ovsdb_idl_row *, const struct ovsdb_datum *);
 void (*unparse)(struct ovsdb_idl_row *);
 };
diff --git a/lib/ovsdb-idl.c b/lib/ovsdb-idl.c
index 227aa5fbfcb2..d474075fa990 100644
--- a/lib/ovsdb-idl.c
+++ b/lib/ovsdb-idl.c
@@ -2871,7 +2871,7 @@ bool
 ovsdb_idl_is_mutable(const struct ovsdb_idl_row *row,
  const struct ovsdb_idl_column *column)
 {
-return column->mutable || (row->new && !row->old);
+return column->mutable_ || (row->new && !row->old);
 }
 
 /* Returns false if 'row' was obtained from the IDL, true if it was initialized
diff --git a/ovsdb/ovsdb-idlc.in b/ovsdb/ovsdb-idlc.in
index f065ef1c68fe..36b7d2700bb6 100755
--- a/ovsdb/ovsdb-idlc.in
+++ b/ovsdb/ovsdb-idlc.in
@@ -1268,7 +1268,7 @@ void
  .type = {
 %(type)s
  },
- .mutable = %(mutable)s,
+ .mutable_ = %(mutable)s,
  .parse = %(s)s_parse_%(c)s,
  .unparse = %(s)s_unparse_%(c)s,
 },\n""" % {'P': prefix.upper(),
-- 
2.13.3

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


Re: [ovs-dev] [patch_v4] dp-packet: Reset DPDK HWOL checksum flags on init.

2017-08-09 Thread Darrell Ball


-Original Message-
From: Aaron Conole 
Date: Wednesday, August 9, 2017 at 12:51 PM
To: Darrell Ball 
Cc: Joe Stringer , Darrell Ball , ovs dev 

Subject: Re: [ovs-dev] [patch_v4] dp-packet: Reset DPDK HWOL checksum flags on 
init.

Darrell Ball  writes:

> Thanks Joe
> I forgot to add your Tested-by to V5; I have been testing this myself;
> but let me know if you would like it added – I can send a V6.

It will automatically be added by patchwork.  It is sufficient to
download (ex: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_799499_mbox=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=LK8s59ajLx5MbmH5Ng8SG1F1nAgKZJ_0JBs7phbl6C8=HRG5wrQrEXCl_AA8uAGbroVSvYGUIQjQkF8HrMRvNYI=
 )

I usually use patchwork when working on a series - if I download it from
patchwork, I can be confident that all the tags are applied properly, so
I won't forget.  Plus, all the discussion happens there, so I can
quickly browse it.

Thanks Aaron
In this case, the Tested-by was applied to V4 and I sent a V5 which did not 
have the Tested-by.
The easiest solution would have been to ask Joe to respond to V5 – well, it is 
moot now anyways with V6 on the way.


The full list is available at:

https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_project_openvswitch_list_=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=LK8s59ajLx5MbmH5Ng8SG1F1nAgKZJ_0JBs7phbl6C8=rqaCq5Jr-Vy-cfQ_t5px-zGtdb55CQn9cIAZCC1PvfE=
 

Thanks, I am on this page most of the day (

It would actually be cool to have a few more admins to troll patchwork
and do things like ping for status (ex:

https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_719492_=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=LK8s59ajLx5MbmH5Ng8SG1F1nAgKZJ_0JBs7phbl6C8=y0RPF47IRVw8BujWHzB9oc7IUihgLuCenLfteZ2vUr4=
  

I don’t have any context on this patch.
Aaron, would you like to resurrect this patch with rebase ?; it is RHEL related.


is this still needed?  it
does seem to mostly apply).  Then we could make sure we don't miss
things.

> Darrell
>
> -Original Message-
> From:  on behalf of Joe Stringer 

> Date: Tuesday, August 8, 2017 at 4:51 PM
> To: Darrell Ball 
> Cc: ovs dev 
> Subject: Re: [ovs-dev] [patch_v4] dp-packet: Reset DPDK HWOL checksum
> flags on init.
>
> On 8 August 2017 at 16:39, Darrell Ball  wrote:
> > Reset the DPDK HWOL checksum flags in dp_packet_init_.
> > The new HWOL bad checksum flag is uninitialized on non-dpdk ports 
and
> > this is noticed as test failures using netdev-dummy ports where the 
bad
> > checksum flag is checked.
> >
> > Fixes: 7451af618e0d ("dp-packet : Update DPDK rx checksum 
validation functions.")
> > CC: Sugesh Chandran 
> > Signed-off-by: Darrell Ball 
> > ---
> 
> Tested-by: Joe Stringer 
> Tested-at: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_joestringer_openvswitch_jobs_262464859=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=jXM8RI10bFYBt8zzW6xxX0MRb4YxJ_uCcOdGTE0sfJo=d664GG1tgARiN5uEJxebCnczlUnMDtHdWluYN0dRc5g=
 
> 
> I'll let those more familiar with this code provide the review.
> ___
> dev mailing list
> d...@openvswitch.org
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=jXM8RI10bFYBt8zzW6xxX0MRb4YxJ_uCcOdGTE0sfJo=kCTOzFrO_3CdwW2mM_wcQZXMHDtzpo8cAuKlHSOcxTw=
 
> 
>
> ___
> dev mailing list
> d...@openvswitch.org
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=LK8s59ajLx5MbmH5Ng8SG1F1nAgKZJ_0JBs7phbl6C8=nnp778JNhzpZBELfmseffsohxJbAQgpKL0BLRS-vlmc=
 


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


[ovs-dev] [PATCHv2 3/4] ovsdb-idl: Avoid new expression.

2017-08-09 Thread Joe Stringer
In C++, 'new' is a keyword. If this is used as the name for a field,
then C++ compilers can get confused about the context and fail to
compile references to such fields. Rename the field to 'new_datum' to
avoid this issue.

Signed-off-by: Joe Stringer 
---
v2: Rebase.
Rename 'new_' to 'new_datum'.
Update comments above 'struct ovsdb_idl_row'.
---
 lib/ovsdb-data.h |   4 +-
 lib/ovsdb-idl-provider.h |  24 +--
 lib/ovsdb-idl.c  | 103 +--
 3 files changed, 68 insertions(+), 63 deletions(-)

diff --git a/lib/ovsdb-data.h b/lib/ovsdb-data.h
index 1bf90d59c30f..756219e9f497 100644
--- a/lib/ovsdb-data.h
+++ b/lib/ovsdb-data.h
@@ -222,10 +222,10 @@ void ovsdb_datum_subtract(struct ovsdb_datum *a,
 /* Generate and apply diffs */
 void ovsdb_datum_diff(struct ovsdb_datum *diff,
   const struct ovsdb_datum *old,
-  const struct ovsdb_datum *new,
+  const struct ovsdb_datum *new_datum,
   const struct ovsdb_type *type);
 
-struct ovsdb_error *ovsdb_datum_apply_diff(struct ovsdb_datum *new,
+struct ovsdb_error *ovsdb_datum_apply_diff(struct ovsdb_datum *new_datum,
const struct ovsdb_datum *old,
const struct ovsdb_datum *diff,
const struct ovsdb_type *type)
diff --git a/lib/ovsdb-idl-provider.h b/lib/ovsdb-idl-provider.h
index aa1fa9390572..94c604620833 100644
--- a/lib/ovsdb-idl-provider.h
+++ b/lib/ovsdb-idl-provider.h
@@ -37,30 +37,30 @@
  * - 'old' points to the data committed to the database and currently
  *   in the row.
  *
- * - 'new == old'.
+ * - 'new_datum == old'.
  *
  * When a transaction is in progress, the situation is a little different.  For
- * a row inserted in the transaction, 'old' is NULL and 'new' points to the
- * row's initial contents.  Otherwise:
+ * a row inserted in the transaction, 'old' is NULL and 'new_datum' points to
+ * the row's initial contents.  Otherwise:
  *
  * - 'old' points to the data committed to the database and currently in
  *   the row.  (This is the same as when no transaction is in progress.)
  *
- * - If the transaction does not modify the row, 'new == old'.
+ * - If the transaction does not modify the row, 'new_datum == old'.
  *
- * - If the transaction modifies the row, 'new' points to the modified
- *   data.
+ * - If the transaction modifies the row, 'new_datum' points to the
+ *   modified data.
  *
- * - If the transaction deletes the row, 'new' is NULL.
+ * - If the transaction deletes the row, 'new_datum' is NULL.
  *
  * Thus:
  *
  * - 'old' always points to committed data, except that it is NULL if the
  *   row is inserted within the current transaction.
  *
- * - 'new' always points to the newest, possibly uncommitted version of the
- *   row's data, except that it is NULL if the row is deleted within the
- *   current transaction.
+ * - 'new_datum' always points to the newest, possibly uncommitted version
+ *   of the row's data, except that it is NULL if the row is deleted within
+ *   the current transaction.
  */
 struct ovsdb_idl_row {
 struct hmap_node hmap_node; /* In struct ovsdb_idl_table's 'rows'. */
@@ -71,9 +71,9 @@ struct ovsdb_idl_row {
 struct ovsdb_datum *old;/* Committed data (null if orphaned). */
 
 /* Transactional data. */
-struct ovsdb_datum *new;/* Modified data (null to delete row). */
+struct ovsdb_datum *new_datum; /* Modified data (null to delete row). */
 unsigned long int *prereqs; /* Bitmap of columns to verify in "old". */
-unsigned long int *written; /* Bitmap of columns from "new" to write. */
+unsigned long int *written; /* Bitmap of "new_datum" columns to write. */
 struct hmap_node txn_node;  /* Node in ovsdb_idl_txn's list. */
 unsigned long int *map_op_written; /* Bitmap of columns pending map ops. */
 struct map_op_list **map_op_lists; /* Per-column map operations. */
diff --git a/lib/ovsdb-idl.c b/lib/ovsdb-idl.c
index d474075fa990..7b244307ddd7 100644
--- a/lib/ovsdb-idl.c
+++ b/lib/ovsdb-idl.c
@@ -775,11 +775,11 @@ ovsdb_idl_check_consistency(const struct ovsdb_idl *idl)
 const struct ovsdb_idl_row *row;
 HMAP_FOR_EACH (row, hmap_node, >rows) {
 size_t n_dsts = 0;
-if (row->new) {
+if (row->new_datum) {
 size_t n_columns = shash_count(>table->columns);
 for (size_t j = 0; j < n_columns; j++) {
 const struct ovsdb_type *type = >columns[j].type;
-const struct ovsdb_datum *datum = >new[j];
+const struct ovsdb_datum *datum = >new_datum[j];
 add_row_references(>key,
datum->keys, 

[ovs-dev] [PATCHv2 4/4] ovsdb-idl: Rename 'old' to 'old_datum'.

2017-08-09 Thread Joe Stringer
Now that the 'new' datum is named 'new_datum', be more consistent by
renaming 'old' to 'old_datum' to match.

Signed-off-by: Joe Stringer 
---
v2: New patch.
---
 lib/ovsdb-data.h |  4 +--
 lib/ovsdb-idl-provider.h | 22 +++---
 lib/ovsdb-idl.c  | 74 +---
 3 files changed, 51 insertions(+), 49 deletions(-)

diff --git a/lib/ovsdb-data.h b/lib/ovsdb-data.h
index 756219e9f497..72c8fe35bce3 100644
--- a/lib/ovsdb-data.h
+++ b/lib/ovsdb-data.h
@@ -221,12 +221,12 @@ void ovsdb_datum_subtract(struct ovsdb_datum *a,
 
 /* Generate and apply diffs */
 void ovsdb_datum_diff(struct ovsdb_datum *diff,
-  const struct ovsdb_datum *old,
+  const struct ovsdb_datum *old_datum,
   const struct ovsdb_datum *new_datum,
   const struct ovsdb_type *type);
 
 struct ovsdb_error *ovsdb_datum_apply_diff(struct ovsdb_datum *new_datum,
-   const struct ovsdb_datum *old,
+   const struct ovsdb_datum *old_datum,
const struct ovsdb_datum *diff,
const struct ovsdb_type *type)
 OVS_WARN_UNUSED_RESULT;
diff --git a/lib/ovsdb-idl-provider.h b/lib/ovsdb-idl-provider.h
index 94c604620833..22a67128736f 100644
--- a/lib/ovsdb-idl-provider.h
+++ b/lib/ovsdb-idl-provider.h
@@ -34,19 +34,19 @@
  *
  * When no transaction is in progress:
  *
- * - 'old' points to the data committed to the database and currently
+ * - 'old_datum' points to the data committed to the database and currently
  *   in the row.
  *
- * - 'new_datum == old'.
+ * - 'new_datum == old_datum'.
  *
  * When a transaction is in progress, the situation is a little different.  For
- * a row inserted in the transaction, 'old' is NULL and 'new_datum' points to
- * the row's initial contents.  Otherwise:
+ * a row inserted in the transaction, 'old_datum' is NULL and 'new_datum'
+ * points to the row's initial contents.  Otherwise:
  *
- * - 'old' points to the data committed to the database and currently in
- *   the row.  (This is the same as when no transaction is in progress.)
+ * - 'old_datum' points to the data committed to the database and currently
+ *   in the row.  (This is the same as when no transaction is in progress.)
  *
- * - If the transaction does not modify the row, 'new_datum == old'.
+ * - If the transaction does not modify the row, 'new_datum == old_datum'.
  *
  * - If the transaction modifies the row, 'new_datum' points to the
  *   modified data.
@@ -55,8 +55,8 @@
  *
  * Thus:
  *
- * - 'old' always points to committed data, except that it is NULL if the
- *   row is inserted within the current transaction.
+ * - 'old_datum' always points to committed data, except that it is NULL if
+ *   the row is inserted within the current transaction.
  *
  * - 'new_datum' always points to the newest, possibly uncommitted version
  *   of the row's data, except that it is NULL if the row is deleted within
@@ -68,11 +68,11 @@ struct ovsdb_idl_row {
 struct ovs_list src_arcs;   /* Forward arcs (ovsdb_idl_arc.src_node). */
 struct ovs_list dst_arcs;   /* Backward arcs (ovsdb_idl_arc.dst_node). */
 struct ovsdb_idl_table *table; /* Containing table. */
-struct ovsdb_datum *old;/* Committed data (null if orphaned). */
+struct ovsdb_datum *old_datum; /* Committed data (null if orphaned). */
 
 /* Transactional data. */
 struct ovsdb_datum *new_datum; /* Modified data (null to delete row). */
-unsigned long int *prereqs; /* Bitmap of columns to verify in "old". */
+unsigned long int *prereqs; /* Bitmap of "old_datum" columns to verify. */
 unsigned long int *written; /* Bitmap of "new_datum" columns to write. */
 struct hmap_node txn_node;  /* Node in ovsdb_idl_txn's list. */
 unsigned long int *map_op_written; /* Bitmap of columns pending map ops. */
diff --git a/lib/ovsdb-idl.c b/lib/ovsdb-idl.c
index 7b244307ddd7..3eb4ecf15589 100644
--- a/lib/ovsdb-idl.c
+++ b/lib/ovsdb-idl.c
@@ -1907,7 +1907,7 @@ ovsdb_idl_row_change__(struct ovsdb_idl_row *row, const 
struct json *row_json,
 }
 
 column_idx = column - table->class_->columns;
-old = >old[column_idx];
+old = >old_datum[column_idx];
 
 error = NULL;
 if (apply_diff) {
@@ -1992,7 +1992,7 @@ ovsdb_idl_row_apply_diff(struct ovsdb_idl_row *row,
 static bool
 ovsdb_idl_row_is_orphan(const struct ovsdb_idl_row *row)
 {
-return !row->old && !row->new_datum;
+return !row->old_datum && !row->new_datum;
 }
 
 /* Returns true if 'row' is conceptually part of the database as modified by
@@ -2025,7 +2025,7 @@ ovsdb_idl_row_parse(struct ovsdb_idl_row *row)
 
 for (i = 0; i < class->n_columns; i++) {
 const struct 

[ovs-dev] [PATCHv2 0/4] Improve C++ support for OVSDB IDL.

2017-08-09 Thread Joe Stringer
In the OVSDB IDL, we use C++ keywords such as "new", "mutable", "class"
for variable and field names. This series adds an underscore after each
usage of these names, to improve the ability to use the IDL from C++ code.
This series focuses primarily on code that exists in the tree; To
address such problems for generated field names that come from an OVSDB
schema, a subsequent patch will still be required. For instance, the
ovs-vswitchd schema has a column named "protected". This ends up as a
field name in the generated lib/vswitch-idl.[ch] code, which causes
similar problems to those addressed by this series.

This series was tested this far using the following diff, but since not
all of the compile errors are addressed yet - specifically those
mentioned above - I'm not submitting the below with this series:

diff --git a/include/openvswitch/automake.mk b/include/openvswitch/automake.mk
index 6bace61593ff..2bcf9c9ebedb 100644
--- a/include/openvswitch/automake.mk
+++ b/include/openvswitch/automake.mk
@@ -29,7 +29,8 @@ openvswitchinclude_HEADERS = \
include/openvswitch/uuid.h \
include/openvswitch/version.h \
include/openvswitch/vconn.h \
-   include/openvswitch/vlog.h
+   include/openvswitch/vlog.h \
+   lib/vswitch-idl.h

 if HAVE_CXX
 # OVS does not use C++ itself, but it provides public header files
@@ -42,7 +43,7 @@ nodist_include_openvswitch_libcxxtest_la_SOURCES = 
include/openvswitch/cxxtest.c
 include/openvswitch/cxxtest.cc: include/openvswitch/automake.mk
$(AM_V_GEN)for header in $(openvswitchinclude_HEADERS); do  \
  echo $$header;\
-   done | sed 's,^include/\(.*\)$$,#include <\1>,' > $@
+   done | sed -e 's,^include/\(.*\)$$,#include <\1>,' -e 
's,^lib/\(.*\)$$,#include <\1>,'  > $@
 endif

 # OVS does not use C++ itself, but it provides public header files
diff --git a/ovsdb/ovsdb-idlc.in b/ovsdb/ovsdb-idlc.in
index 9c674e7f5e80..d5562add4410 100755
--- a/ovsdb/ovsdb-idlc.in
+++ b/ovsdb/ovsdb-idlc.in
@@ -136,7 +136,11 @@ def printCIDLHeader(schemaFile):
 #include "ovsdb-data.h"
 #include "ovsdb-idl-provider.h"
 #include "smap.h"
-#include "uuid.h"''' % {'prefix': prefix.upper()})
+#include "uuid.h"
+
+#ifdef  __cplusplus
+extern "C" {
+#endif''' % {'prefix': prefix.upper()})

 for tableName, table in sorted(schema.tables.items()):
 structName = "%s%s" % (prefix, tableName.lower())
@@ -1050,6 +1054,10 @@ const char *
 {
 return "%s";
 }
+
+#ifdef  __cplusplus
+}
+#endif
 """ % (prefix, schema.version))
 
 

Joe Stringer (4):
  ovsdb-idl: Avoid class declaration.
  ovsdb-idl: Avoid mutable type specifier.
  ovsdb-idl: Avoid new expression.
  ovsdb-idl: Rename 'old' to 'old_datum'.

 lib/db-ctl-base.c|   4 +-
 lib/ovsdb-data.h |   8 +-
 lib/ovsdb-idl-provider.h |  42 +++
 lib/ovsdb-idl.c  | 307 ---
 ovsdb/ovsdb-idlc.in  |   2 +-
 5 files changed, 185 insertions(+), 178 deletions(-)

-- 
2.13.3

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


[ovs-dev] [PATCH] dp-packet: Use OVS_UNUSED to mark possibly unused parameters.

2017-08-09 Thread Ben Pfaff
This is the way usually used in OVS.

Signed-off-by: Ben Pfaff 
---
 lib/dp-packet.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/lib/dp-packet.h b/lib/dp-packet.h
index 9dbb611d95fb..8f52feeefa39 100644
--- a/lib/dp-packet.h
+++ b/lib/dp-packet.h
@@ -615,46 +615,46 @@ dp_packet_rss_invalidate(struct dp_packet *p)
 }
 
 static inline bool
-dp_packet_ip_checksum_valid(struct dp_packet *p)
+dp_packet_ip_checksum_valid(struct dp_packet *p OVS_UNUSED)
 {
 #ifdef DPDK_NETDEV
 return (p->mbuf.ol_flags & PKT_RX_IP_CKSUM_MASK) ==
 PKT_RX_IP_CKSUM_GOOD;
 #else
-return 0 && p;
+return false;
 #endif
 }
 
 static inline bool
-dp_packet_ip_checksum_bad(struct dp_packet *p)
+dp_packet_ip_checksum_bad(struct dp_packet *p OVS_UNUSED)
 {
 #ifdef DPDK_NETDEV
 return (p->mbuf.ol_flags & PKT_RX_IP_CKSUM_MASK) ==
 PKT_RX_IP_CKSUM_BAD;
 #else
-return 0 && p;
+return false;
 #endif
 }
 
 static inline bool
-dp_packet_l4_checksum_valid(struct dp_packet *p)
+dp_packet_l4_checksum_valid(struct dp_packet *p OVS_UNUSED)
 {
 #ifdef DPDK_NETDEV
 return (p->mbuf.ol_flags & PKT_RX_L4_CKSUM_MASK) ==
 PKT_RX_L4_CKSUM_GOOD;
 #else
-return 0 && p;
+return false;
 #endif
 }
 
 static inline bool
-dp_packet_l4_checksum_bad(struct dp_packet *p)
+dp_packet_l4_checksum_bad(struct dp_packet *p OVS_UNUSED)
 {
 #ifdef DPDK_NETDEV
 return (p->mbuf.ol_flags & PKT_RX_L4_CKSUM_MASK) ==
 PKT_RX_L4_CKSUM_BAD;
 #else
-return 0 && p;
+return false;
 #endif
 }
 
-- 
2.10.2

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


Re: [ovs-dev] [PATCH v3 4/6] dpif-netdev: Change rxq_scheduling to use rxq processing cycles.

2017-08-09 Thread Greg Rose

On 08/09/2017 08:47 AM, Kevin Traynor wrote:

On 08/08/2017 07:15 PM, Greg Rose wrote:
> On 08/01/2017 08:58 AM, Kevin Traynor wrote:
>> Previously rxqs were assigned to pmds by round robin in
>> port/queue order.
>>
>> Now that we have the processing cycles used for existing rxqs,
>> use that information to try and produced a better balanced
>> distribution of rxqs across pmds. i.e. given multiple pmds, the
>> rxqs which have consumed the largest amount of processing cycles
>> will be placed on different pmds.
>>
>> The rxqs are sorted by their processing cycles and assigned (in
>> sorted order) round robin across pmds.
>>
>> Signed-off-by: Kevin Traynor 
>> ---
>>Documentation/howto/dpdk.rst |  7 +
>>lib/dpif-netdev.c| 73
>> +++-
>>2 files changed, 66 insertions(+), 14 deletions(-)
>>
>> diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
>> index af01d3e..a969285 100644
>> --- a/Documentation/howto/dpdk.rst
>> +++ b/Documentation/howto/dpdk.rst
>> @@ -119,4 +119,11 @@ After that PMD threads on cores where RX queues
>> was pinned will become
>>  thread.
>>
>> +If pmd-rxq-affinity is not set for rxqs, they will be assigned to
>> pmds (cores)
>> +automatically. The processing cycles that have been required for each
>> rxq
>> +will be used where known to assign rxqs with the highest consumption of
>> +processing cycles to different pmds.
>> +
>> +Rxq to pmds assignment takes place whenever there are configuration
>> changes.
>> +
>>QoS
>>---
>> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
>> index 25a521a..a05e586 100644
>> --- a/lib/dpif-netdev.c
>> +++ b/lib/dpif-netdev.c
>> @@ -3295,8 +3295,29 @@ rr_numa_list_destroy(struct rr_numa_list *rr)
>>}
>>
>> +/* Sort Rx Queues by the processing cycles they are consuming. */
>> +static int
>> +rxq_cycle_sort(const void *a, const void *b)
>> +{
>> +struct dp_netdev_rxq * qa;
>> +struct dp_netdev_rxq * qb;
>> +
>> +qa = *(struct dp_netdev_rxq **) a;
>> +qb = *(struct dp_netdev_rxq **) b;
>> +
>> +if (dp_netdev_rxq_get_cycles(qa, RXQ_CYCLES_PROC_LAST) >=
>> +dp_netdev_rxq_get_cycles(qb, RXQ_CYCLES_PROC_LAST)) {
>> +return -1;
>> +}
>> +
>> +return 1;
>> +}
>> +
>>/* Assign pmds to queues.  If 'pinned' is true, assign pmds to pinned
>> * queues and marks the pmds as isolated.  Otherwise, assign non
>> isolated
>> * pmds to unpinned queues.
>> *
>> + * If 'pinned' is false queues will be sorted by processing cycles
>> they are
>> + * consuming and then assigned to pmds in round robin order.
>> + *
>> * The function doesn't touch the pmd threads, it just stores the
>> assignment
>> * in the 'pmd' member of each rxq. */
>> @@ -3306,18 +3327,14 @@ rxq_scheduling(struct dp_netdev *dp, bool
>> pinned) OVS_REQUIRES(dp->port_mutex)
>>struct dp_netdev_port *port;
>>struct rr_numa_list rr;
>> -
>> -rr_numa_list_populate(dp, );
>> +struct dp_netdev_rxq ** rxqs = NULL;
>> +int i, n_rxqs = 0;
>> +struct rr_numa *numa = NULL;
>> +int numa_id;
>>
>>HMAP_FOR_EACH (port, node, >ports) {
>> -struct rr_numa *numa;
>> -int numa_id;
>> -
>>if (!netdev_is_pmd(port->netdev)) {
>>continue;
>>}
>>
>> -numa_id = netdev_get_numa_id(port->netdev);
>> -numa = rr_numa_list_lookup(, numa_id);
>> -
>>for (int qid = 0; qid < port->n_rxq; qid++) {
>>struct dp_netdev_rxq *q = >rxqs[qid];
>> @@ -3337,17 +3354,45 @@ rxq_scheduling(struct dp_netdev *dp, bool
>> pinned) OVS_REQUIRES(dp->port_mutex)
>>}
>>} else if (!pinned && q->core_id == OVS_CORE_UNSPEC) {
>> -if (!numa) {
>> -VLOG_WARN("There's no available (non isolated)
>> pmd thread "
>> -  "on numa node %d. Queue %d on port
>> \'%s\' will "
>> -  "not be polled.",
>> -  numa_id, qid,
>> netdev_get_name(port->netdev));
>> +if (n_rxqs == 0) {
>> +rxqs = xmalloc(sizeof *rxqs);
>>} else {
>> -q->pmd = rr_numa_get_pmd(numa);
>> +rxqs = xrealloc(rxqs, sizeof *rxqs * (n_rxqs + 1));
>>}
>> +/* Store the queue. */
>> +rxqs[n_rxqs++] = q;
>>}
>>}
>>}
>>
>> +if (n_rxqs > 1) {
>> +/* Sort the queues in order of the processing cycles
>> + * they consumed during their last pmd interval. */
>> +qsort(rxqs, n_rxqs, sizeof *rxqs, rxq_cycle_sort);
>> +}
>> +
>> +rr_numa_list_populate(dp, );
>> +/* Assign the sorted queues to pmds in round robin. */
>> +for (i = 0; i < n_rxqs; i++) {
>> +numa_id = 

Re: [ovs-dev] [PATCH v3] route-table: Remove netdevs in netdev_hash when deleted

2017-08-09 Thread Tonghao Zhang
why not remove the function of route_table_link_del to name_table_change() ?

On Wed, Aug 9, 2017 at 3:41 PM, fukaige  wrote:
> From: Kaige Fu 
>
> Start a virtual machine with its backend tap device attached to a brought up 
> linux bridge.
> If we delete the linux bridge when vm is still running, we'll get the 
> following error when
> trying to create a ovs bridge with the same name.
>
> The reason is that ovs-router subsystem add the linux bridge into 
> netdev_shash, but does
> not remove it when the bridge is deleted in the situation. When the bridge is 
> deleted, ovs
> will receive a RTM_DELLINK msg, take this chance to remove the bridge in 
> netdev_shash.
>
> ovs-vsctl: Error detected while setting up 'br-eth'.  See ovs-vswitchd log 
> for details.
>
> ovs-vswitchd log:
> 2017-05-11T03:45:25.293Z|00026|ofproto_dpif|INFO|system@ovs-system: Datapath 
> supports recirculation
> 2017-05-11T03:45:25.293Z|00027|ofproto_dpif|INFO|system@ovs-system: MPLS 
> label stack length probed as 1
> 2017-05-11T03:45:25.293Z|00028|ofproto_dpif|INFO|system@ovs-system: Datapath 
> supports unique flow ids
> 2017-05-11T03:45:25.293Z|00029|ofproto_dpif|INFO|system@ovs-system: Datapath 
> supports ct_state
> 2017-05-11T03:45:25.293Z|00030|ofproto_dpif|INFO|system@ovs-system: Datapath 
> supports ct_zone
> 2017-05-11T03:45:25.293Z|00031|ofproto_dpif|INFO|system@ovs-system: Datapath 
> supports ct_mark
> 2017-05-11T03:45:25.293Z|00032|ofproto_dpif|INFO|system@ovs-system: Datapath 
> supports ct_label
> 2017-05-11T03:45:25.364Z|1|ofproto_dpif_upcall(handler226)|INFO|received 
> packet on unassociated datapath port 0
> 2017-05-11T03:45:25.368Z|00033|netdev_linux|WARN|ethtool command 
> ETHTOOL_GFLAGS on network device br-eth failed: No such device
> 2017-05-11T03:45:25.368Z|00034|dpif|WARN|system@ovs-system: failed to add 
> br-eth as port: No such device
> 2017-05-11T03:45:25.368Z|00035|bridge|INFO|bridge br-eth: using datapath ID 
> 2a51cf9f2841
> 2017-05-11T03:45:25.368Z|00036|connmgr|INFO|br-eth: added service controller 
> "punix:/var/run/openvswitch/br-eth.mgmt"
>
> Signed-off-by: Kaige Fu 
> ---
>  lib/route-table.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/lib/route-table.c b/lib/route-table.c
> index 67fda31..5107056 100644
> --- a/lib/route-table.c
> +++ b/lib/route-table.c
> @@ -33,6 +33,7 @@
>  #include "ovs-router.h"
>  #include "packets.h"
>  #include "rtnetlink.h"
> +#include "tnl-ports.h"
>  #include "openvswitch/vlog.h"
>
>  /* Linux 2.6.36 added RTA_MARK, so define it just in case we're building with
> @@ -79,6 +80,7 @@ static int route_table_reset(void);
>  static void route_table_handle_msg(const struct route_table_msg *);
>  static int route_table_parse(struct ofpbuf *, struct route_table_msg *);
>  static void route_table_change(const struct route_table_msg *, void *);
> +static void route_table_link_del(const struct rtnetlink_change *, void *);
>  static void route_map_clear(void);
>
>  static void name_table_init(void);
> @@ -112,6 +114,8 @@ route_table_init(void)
>  nln_notifier_create(nln, RTNLGRP_IPV6_ROUTE,
>  (nln_notify_func *) route_table_change, NULL);
>
> +rtnetlink_notifier_create(route_table_link_del, NULL);
> +
>  route_table_reset();
>  name_table_init();
>
> @@ -297,6 +301,17 @@ route_table_change(const struct route_table_msg *change 
> OVS_UNUSED,
>  }
>
>  static void
> +route_table_link_del(const struct rtnetlink_change *change,
> + void *aux OVS_UNUSED)
> +{
> +if(change && change->nlmsg_type == RTM_DELLINK) {
> +if(change->ifname) {
> +tnl_port_map_delete_ipdev(change->ifname);
> +}
> +}
> +}
> +
> +static void
>  route_table_handle_msg(const struct route_table_msg *change)
>  {
>  if (change->relevant && change->nlmsg_type == RTM_NEWROUTE) {
> --
> 1.8.3.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 net-next] openvswitch: add NSH support

2017-08-09 Thread Yang, Yi Y
struct ovs_action_encap_nsh is the only one way we transfer all the data for 
encap_nsh, netlink allows variable attribute, so I don't think we break netlink 
convention or abuse this variable feature.

Even if we bring nested attributes to handle this, OVS_ACTION_ATTR_ENCAP_NSH is 
still length-variable, OVS_NSH_ATTR_MD2 is also length-variable (it can be from 
0 to 248), so I don't think such way can avoid the issue you're addressing.

The result will be worse, it will make many difficulties when we transfer all 
the data for encap_nsh between OVS' components.

-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org] 
Sent: Thursday, August 10, 2017 4:54 AM
To: Yang, Yi Y 
Cc: Jan Scheurich ; d...@openvswitch.org; 
net...@vger.kernel.org; Jiri Benc ; da...@davemloft.net; 
Zoltán Balogh 
Subject: Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support

On Wed, Aug 09, 2017 at 08:12:36PM +, Yang, Yi Y wrote:
> Ben, do you mean we bring two new attributes (OVS_NSH_ATTR_MD1 and
> OVS_NSH_ATTR_MD2) and embed one of them in OVS_ACTION_ATTR_ENCAP_NSH?

Yes.

> Anyway we need to use a struct or something else to transfer those 
> metadata between functions, how do you think we can handle this 
> without metadata in struct ovs_action_encap_nsh? I mean how we handle 
> the arguments for function encap_nsh.

I guess that a pointer to the embedded nlattr with type OVS_NSH_ATTR_MD1 or 
OVS_NSH_ATTR2 should work OK.

Keep in mind that I'm not a kernel-side maintainer of any kind.  I am only 
passing along what I've perceived to be common Netlink protocol design patterns.

> -Original Message-
> From: netdev-ow...@vger.kernel.org 
> [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Ben Pfaff
> Sent: Thursday, August 10, 2017 2:09 AM
> To: Yang, Yi Y 
> Cc: Jan Scheurich ; d...@openvswitch.org; 
> net...@vger.kernel.org; Jiri Benc ; 
> da...@davemloft.net; Zoltán Balogh 
> Subject: Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support
> 
> On Wed, Aug 09, 2017 at 09:41:51AM +, Yang, Yi Y wrote:
> > Hi,  Jan
> > 
> > I have worked out a patch, will send it quickly for Ben. In 
> > addition, I also will send out a patch to change encap_nsh 
> > _nsh to push_nsh and pop_nsh. Per comments from all the 
> > people, we all agreed to do so :-)
> > 
> > diff --git a/datapath/linux/compat/include/linux/openvswitch.h
> > b/datapath/linux/compat/include/linux/openvswitch.h
> > index bc6c94b..4936c12 100644
> > --- a/datapath/linux/compat/include/linux/openvswitch.h
> > +++ b/datapath/linux/compat/include/linux/openvswitch.h
> > @@ -793,7 +793,7 @@ struct ovs_action_push_eth {
> > struct ovs_key_ethernet addresses;  };
> > 
> > -#define OVS_ENCAP_NSH_MAX_MD_LEN 16
> > +#define OVS_ENCAP_NSH_MAX_MD_LEN 248
> >  /*
> >   * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
> >   * @flags: NSH header flags.
> > @@ -809,7 +809,7 @@ struct ovs_action_encap_nsh {
> >  uint8_t mdlen;
> >  uint8_t np;
> >  __be32 path_hdr;
> > -uint8_t metadata[OVS_ENCAP_NSH_MAX_MD_LEN];
> > +uint8_t metadata[];
> >  };
> 
> This brings the overall format of ovs_action_encap_nsh to:
> 
> struct ovs_action_encap_nsh {
> uint8_t flags;
> uint8_t mdtype;
> uint8_t mdlen;
> uint8_t np;
> __be32 path_hdr;
> uint8_t metadata[];
> };
> 
> This is an unusual format for a Netlink attribute.  More commonly, one would 
> put variable-length data into an attribute of its own, which allows that data 
> to be handled using the regular Netlink means.  Then the mdlen and metadata 
> members could be removed, since they would be part of the additional 
> attribute, and one might expect the mdtype member to be removed as well since 
> each type of metadata would be in a different attribute type.
> 
> So, a format closer to what I expect to see in Netlink is something 
> like
> this:
> 
> /**
>  * enum ovs_nsh_attr - Metadata attributes for %OVS_ACTION_ENCAP_NSH action.
>  *
>  * @OVS_NSH_ATTR_MD1: Contains 16-byte NSH type-1 metadata.
>  * @OVS_NSH_ATTR_MD2: Contains 0- to 255-byte variable-length NSH 
> type-2
>  * metadata. */
> enum ovs_nsh_attr {
> OVS_NSH_ATTR_MD1,
> OVS_NSH_ATTR_MD2
> };
> 
> /*
>  * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
>  *
>  * @path_hdr: NSH service path id and service index.
>  * @flags: NSH header flags.
>  * @np: NSH next_protocol: Inner packet type.
>  *
>  * Followed by either %OVS_NSH_ATTR_MD1 or %OVS_NSH_ATTR_MD2 attribute.
>  */
> struct ovs_action_encap_nsh {
> __be32 path_hdr;
> uint8_t flags;
> uint8_t np;
> };
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] Sea un Excelente Líder - En Línea

2017-08-09 Thread Invitación
En línea y en Vivo / Para todo su Equipo con una sola Conexión 

Conviértase en un Excelente Líder - técnicas y Consejos 
25 de Agosto - Online en Vivo - 10:00 a 13:00 y de 15:00 a 18:00Hrs   
 
Aprenda a manejar con habilidad las metas y objetivos de su área y conducir a 
su personal al logro de los mismos, supervisar con una metodología de trabajo 
para lograr que las cosas se hagan bien, con calidad, productivamente y de 
acuerdo a los requerimientos del cliente interno y externo. 

TEMARIO: 

1. Planeación de actividades para lograr metas, objetivos y resultados. 

2. La importancia del control y la evaluación. 

3. Factores que afectan su habilidad de dirigir.

4. Cómo delegar con efectividad.

- Y mucho más. 




 
¿Requiere la información a la Brevedad?
responda este email con la palabra: Líder.
Junto con los siguientes datos: Nombre, Teléfono y empresa.

centro telefónico:018002129393


 
Lic. Arturo López
Coordinador de Eventos


¿Demasiados mensajes en su cuenta? Responda este mensaje indicando que solo 
desea recibir CALENDARIO y sólo recibirá un correo al mes. Si desea cancelar la 
suscripción, solicite su BAJA.
 

 

 



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


Re: [ovs-dev] [PATCH trivial 1/3] netdev-dummy: Fix minor style variation.

2017-08-09 Thread Joe Stringer
On 9 August 2017 at 13:46, Ben Pfaff  wrote:
> On Wed, Aug 09, 2017 at 01:38:05PM -0700, Joe Stringer wrote:
>> Signed-off-by: Joe Stringer 
>
> For all three patches:
> Acked-by: Ben Pfaff 

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


  1   2   >