Re: [ovs-dev] [PATCH v3 11/16] userspace: add non-tap (l3) support to GRE vports

This patch has been superseded by patch series https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328391.html, specifically https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328395.html Please exclude from review. Regards, Jan > -Original Message- > From:

Re: [ovs-dev] [PATCH v3 10/16] userspace: add layer 3 flow and switching support

This patch has been superseded by patch series https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328391.html, specifically https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328396.html Please exclude from review. Regards, Jan > -Original Message- > From:

Re: [ovs-dev] [PATCH v3 09/16] userspace: add support for pop_eth and push_eth actions

This patch has been superseded by patch series https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328391.html specifically patch https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328394.html Please exclude from review. BR, Jan > -Original Message- > From:

Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

in the net-next and OVS tree kernel module. /Jan > -Original Message- > From: Joe Stringer [mailto:j...@ovn.org] > Sent: Tuesday, 07 February, 2017 18:55 > To: Yang, Yi Y <yi.y.y...@intel.com> > Cc: Jan Scheurich <jan.scheur...@ericsson.com>; d...@openvswitch.org >

[ovs-dev] [PATCH 7/7] ofproto-dpif-xlate: refactor compose_output_action__

into separate functions. Signed-off-by; Jan Scheurich <jan.scheur...@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.bal...@ericsson.com> --- ofproto/ofproto-dpif-xlate.c | 432 +++ 1 file changed, 230 insertions(+), 202 deletions(-) diff --g

[ovs-dev] [PATCH 6/7] dpif-netlink: Don't send PACKET_TYPE to kernel

The kernel datapath does not support the packet_type match field. Instead it encodes the packet type implicitly by the presence or absence of the Ethernet attribute in the flow key and mask. This patch filters the PACKET_TYPE attribute out of netlink flow key and mask to be sent to the kernel

[ovs-dev] [PATCH 1/7] userspace: Add packet_type in dp_packet and flow

on packet_type instead. New dp_packets are initialized with packet_type Ethernet. Ports that receive L3 packets will have to explicitly adjust the packet_type. Signed-off-by: Jean Tourrilhes <j...@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheur...@ericsson.com> Co-authored-by: Z

[ovs-dev] [PATCH 3/7] userspace: Switching of L3 packets in L2 pipeline

appropriately in dpif-netdev. Signed-off-by: Lorand Jakab <loja...@cisco.com> Signed-off-by: Simon Horman <simon.hor...@netronome.com> Signed-off-by: Jiri Benc <jb...@redhat.com> Signed-off-by: Yi Yang <yi.y.y...@intel.com> Signed-off-by: Jan Scheurich <jan.scheur...@ericsson.

[ovs-dev] [PATCH 5/7] userspace: L3 tunnel support for GRE and LISP

e L3 tunnel handling. Signed-off-by: Simon Horman <simon.hor...@netronome.com> Signed-off-by: Jiri Benc <jb...@redhat.com> Signed-off-by: Yi Yang <yi.y.y...@intel.com> Signed-off-by; Jan Scheurich <jan.scheur...@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.bal...@ericss

[ovs-dev] [PATCH 2/7] userspace: Support for push_eth and pop_eth actions

onome.com> Signed-off-by: Jiri Benc <jb...@redhat.com> Signed-off-by: Yi Yang <yi.y.y...@intel.com> Signed-off-by: Jean Tourrilhes <j...@labs.hpe.com> Signed-off-by: Jan Scheurich <jan.scheur...@ericsson.com> Co-authored-by: Zoltan Balogh <zoltan.bal...@ericsson.com>

[ovs-dev] [PATCH 4/7] ofproto-dpif-upcall: Intialize dump-seq of new flow to zero

This forces updating of flow stat at the next re-validation, even for flows that are being created when the revalidation has already commenced. It enables reliable testing of fast path flow stats using ovs-appctl time/warp after flow creation. Signed-off-by: Jan Scheurich <jan.sch

Re: [ovs-dev] [PATCH 1/1] dpif-netdev: Conditional EMC insert

It's not a big deal, since the most important use case we have for dpif-netdev is with dpdk, but I'd still like the code to behave similarly on different platforms. How about defining a function that uses random_uint32 when compiling without DPDK? For testing it's not that simple, because

[ovs-dev] OVS - ODL Sync on OF Bundle in 1.3

Rescheduled to Wednesday due to unavailability of key participants. @Jarno: As you are the OVS brain behind bundles. Do you have the chance to join for a short time to discuss some details regarding OF 1.3 bundle implementation? Hi Jarno, OpenDaylight folks are finally starting to implement

Re: [ovs-dev] OVS - ODL Sync on OF Bundle in 1.3

Hi, A local dial-in number for Slovakia participants can be found under the link “Find a local number”: Slovak Republic ‪+421249499488‬‪ English (United States)‬ BR, Jan -Original Appointment- From: Jan Scheurich Sent: Wednesday, 18 January, 2017 16:23

[ovs-dev] OVS - ODL Sync on OF Bundle in 1.3

We'll use below webex instead of Lync/SkypeFB: https://meetings.webex.com/collabs/#/meetings/detail?uuid=MBFUHFYE8TRG3NPX76F4PLRS2N-3OWH=231184.55753 Rescheduled to Wednesday due to unavailability of key participants. @Jarno: As you are the OVS brain behind

Re: [ovs-dev] [PATCH v3] dpif-netdev: Change definitions of 'idle' & 'processing' cycles

> -Original Message- > From: Kevin Traynor [mailto:ktray...@redhat.com] > Sent: Friday, 17 February, 2017 17:38 > > If there are multiple queues in a poll list and only one has packets, > the cycles polling the empty queues for packets will be counted in the > processing time - whereas

Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

for rtnetlink and compat tunnel configuration for L3 tunnels are added. BR, Jan > -Original Message- > From: Yang, Yi Y [mailto:yi.y.y...@intel.com] > Sent: Wednesday, 08 February, 2017 06:31 > To: Jan Scheurich <jan.scheur...@ericsson.com>; Joe Stringer <j...@ovn.o

Re: [ovs-dev] [PATCH v4] dpif-netdev: Conditional EMC insert

I was also struggling a bit with this conceptual mismatch. N really is the reciprocal probability (P = 1/N), and values above a few 1000s are probably not very meaningful. Specifying in P in percent is certainly easier to understand, the only issue I have is that integer values would limit

Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

Hi Valentine, On 2017-02-09 08:58, Valentine Sinitsyn wrote: This L3 patchset looks similar to what we did internally with OVS 2.6 to add support for IPv6 tunnels. Could you please confirm that ovs-dpctl reports correct statistics with this patchset when one uses in-kernel Linux datapath? We

Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

patches, that is why I included those three user space patches in my patch set. I don't know what order ovs maintainers will merge them in. I can only focus on userspace support for vxlan-gpe if ovs maintainers really merge your patches first. -Original Message- From: Jan Scheurich

Re: [ovs-dev] [PATCH v6] dpif-netdev: Conditional EMC insert

Thanks Ciara, But why have you not moved the atomic read of min into the function, too? Jan > -Original Message- > From: Ciara Loftus [mailto:ciara.lof...@intel.com] > Sent: Thursday, 09 February, 2017 16:42 > To: d...@openvswitch.org > Cc: jan.scheur...@web.de; diproiet...@ovn.org;

Re: [ovs-dev] [PATCH v4] dpif-netdev: Conditional EMC insert

I'd suggest not to duplicate the code around the calls to emc_probabilistic_insert() but move it into the function itself, passing pmd instead of pmd->flow_cache as first argument. Jan > @@ -4194,7 +4231,15 @@ handle_packet_upcall(struct dp_netdev_pmd_thread *pmd, > struct dp_packet *packet,

[ovs-dev] PTAP, EXT-382 and NSH: Minutes of meeting 2016-01-17

Date: 2016-12-21, 17-18:30 CET Participants: Jarno R, Ben P, Ben M-C, Jiri B, Simon H, Zoltan B, Jan S Summary: * Status/progress/coordination of work packages: 1 - L3 packet handling in kernel datapath (net-next) Upstreaming to net-next done, depending on Eric G's VLAN fixes.

[ovs-dev] Sync on PTAP, EXT-382 and NSH

Hi, Please be invited to the next sync meeting. Minutes of the previous meeting: https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327738.html Actions Points: AP-1 (Jarno): Coordinate review of Yi's backported net-next patches AP-2 (Jiri) Check the ability of the kernel datapath to

[ovs-dev] PTAP, EXT-382 and NSH: Minutes of meeting 2017-02-28

a dedicated meeting with Jarno for technical discussion. * No update on the NSH specification for ONF. BR, Jan -Original Appointment- From: Jan Scheurich Sent: Sunday, 18 December, 2016 15:34 To: Jan Scheurich; Zoltán Balogh; Yang, Yi Y (yi.y.y...@intel.com); Jiri

Re: [ovs-dev] Sync on PTAP, EXT-382 and NSH

Hi, Thank you for the constructive meeting. Here are my notes: Date: 2016-12-15, 8-9:30 am CET Participants: Yi Yang, Danny Zhou, Zoltan Balogh, Jan Scheurich Summary: * Went through the proposed solution for NSH based on PTAP and generic encap/decap in the doc: https

Re: [ovs-dev] Unwildcarding of fields modified by set_field action

AM, Jan Scheurich <jan.scheur...@web.de> wrote: On 2017-01-11 01:14, Jarno Rajahalme wrote: Unwildcarding of set fields is only done for practical reasons in the userspace code, and could be optimized away, especially for recent enough datapaths that implement the masked set action. Cur

[ovs-dev] Sync on PTAP, EXT-382 and NSH

Hi, Please be invited to the first sync meeting in the new year. Agenda: * Status/progress/coordination of work packages: 1 - L3 packets in kernel datapath (net-next) 2 - Layer 3 tunnel configuration 3 - L3 ports in non-PTAP bridge 6 - VXLAN-GPE tunnel 4 -

Re: [ovs-dev] Sync on PTAP, EXT-382 and NSH

y to merge about one month after (including kernel patches and ovs patches) I'm wondering if you guys can make a form to list pros and cons for the old implementation way and this new one in order that every people can clearly know what the advantages and disadvantages for them are. From: Jan

Re: [ovs-dev] [PATCH v2 09/17] userspace: add support for pop_eth and push_eth actions

This patch is not in line with the ongoing work to support L3 tunnels on legacy (non packet type-aware) OVS bridges as specified in https://docs.google.com/document/d/1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8/edit?usp=sharing To avoid extensive rework, we suggest to replace the patch with

Re: [ovs-dev] [PATCH v2 10/17] userspace: add layer 3 flow and switching support

This patch is not in line with the ongoing work to support L3 tunnels on legacy (non packet type-aware) OVS bridges as specified in https://docs.google.com/document/d/1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8/edit?usp=sharing To avoid extensive rework, we suggest to replace the patch with

Re: [ovs-dev] [PATCH v2 11/17] userspace: add non-tap (l3) support to GRE vports

This patch is not in line with the ongoing work to support L3 tunnels on legacy (non packet type-aware) OVS bridges as specified in https://docs.google.com/document/d/1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8/edit?usp=sharing To avoid extensive rework, we suggest to replace the patch with

Re: [ovs-dev] Sync on PTAP, EXT-382 and NSH

e solution actually carry over easily. From the OF controller perspective, the NSH pipeline can be just as simple as before, as we have tried to demonstrate with the example flows in the document. *From:*Jan Scheurich [mailto:jan.scheur...@web.de] *Sent:* Friday, December 30, 2016 6:34 PM *To:

[ovs-dev] Sync on PTAP, EXT-382 and NSH

Hello all, I would like to call for a final sync meeting before the Christmas break. Now that we have gone through the main aspects of the design, I would like to focus on how to divide the entire function into manageable pieces, discuss the potential work split, an integration anatomy and a

Re: [ovs-dev] Sync on PTAP, EXT-382 and NSH

o Review of patches mainly through the ovs-dev mailing list o Use tools like git citool to break up larger patches into a series of smaller patches for review -Original Appointment- From: Jan Scheurich Sent: Sunday, 18 December, 2016 15:34 To: Jan

[ovs-dev] Sync on PTAP, EXT-382 and NSH

Hi, The team is making good progress in preparing the various patch packages. We have a lot of things working in our gitlab repo (https://gitlab.com/JScheurich/ovs). v3 of the L3 tunneling patches are out on the mailing list since a week

[ovs-dev] Sync on PTAP, EXT-382 and NSH: Mon 2017-03-13, 17:00 CET

Hi, Please be invited to our next sync meeting: Mon 13 March, 5pm CET. Agenda: * Review/Discussion of current patch packages, e.g. o Display format for packet_type field in match and flow keys o packet_type in struct dp_packet or struct pkt_metadata * Status/Planning of

Re: [ovs-dev] [PATCH 1/7] userspace: Add packet_type in dp_packet and flow

Hi Ben, Thanks for the review. Please find some answers below. Jan > -Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Friday, 03 March, 2017 19:14 > To: Jan Scheurich <jan.scheur...@ericsson.com> > Cc: d...@openvswitch.org > Subject: Re: [ovs-de

Re: [ovs-dev] [PATCH 3/7] userspace: Switching of L3 packets in L2 pipeline

> Please don't add comments about changes, like this one. Readers should > not have to understand the history to understand the code: > +if (put->flags & DPIF_FP_MODIFY) { > +/* Removed the additional check > + * flow_equal(, _flow->flow) as a) the > +

Re: [ovs-dev] [PATCH 5/7] userspace: L3 tunnel support for GRE and LISP

> I'm going to defer review on this and the later patches to the next > version. OK. We'll post an updated series when the open issues are sorted out. The biggest issue is the display format of packet_type (due to volume of unit test updates involved). The other open question to solve is

Re: [ovs-dev] [PATCH 2/7] userspace: Support for push_eth and pop_eth actions

> > Signed-off-by: Lorand Jakab <loja...@cisco.com> > > Signed-off-by: Simon Horman <simon.hor...@netronome.com> > > Signed-off-by: Jiri Benc <jb...@redhat.com> > > Signed-off-by: Yi Yang <yi.y.y...@intel.com> > > Signed-off-by: Jean Tourrilhe

Re: [ovs-dev] [PATCH 4/7] ofproto-dpif-upcall: Intialize dump-seq of new flow to zero

> > This forces updating of flow stat at the next re-validation, even for > > flows that are being created when the revalidation has already commenced. > > > > It enables reliable testing of fast path flow stats using ovs-appctl > > time/warp after flow creati

Re: [ovs-dev] dpif-netdev: Assign ports to pmds on non-local numa node.

I support Billy's point here. There are a number of constraints/trade-offs that can lead to an OVS deployments in OpenStack with e.g. a single PMD. Without this change, a dual socket system is effectively rendered use-less. At least one socket is lost for running VMs. BR, Jan > -Original

Re: [ovs-dev] [PATCH v2 0/8] userspace: Support for L3 tunneling

openvswitch.org> > Cc: Jan Scheurich <jan.scheur...@ericsson.com>; Georg Schmuecking > <georg.schmueck...@ericsson.com> > Subject: [PATCH v2 0/8] userspace: Support for L3 tunneling > > From: Jan Scheurich <jan.scheur...@ericssom.com> > > This patch set i

Re: [ovs-dev] Yang, Yi Y sent you a message in Skype for Business-FYI: basically I have worked out a ovs nsh version per their requirements

path which can deal with both MD1 and MD2 already today. BR Jan From: Yang, Yi Y [mailto:yi.y.y...@intel.com] Sent: Wednesday, 16 August, 2017 01:36 To: Jan Scheurich <jan.scheur...@ericsson.com>; Zoltán Balogh <zoltan.bal...@ericsson.com> Subject: RE: Yang, Yi Y sent you a message in Sk

Re: [ovs-dev] [RFC PATCH 1/1] dpif-netdev : Include Rxq processing cycles

I believe that queue-related cycles stats should be part of the pmd-rxq-show output, possibly guarded by some command option. The queue statistics should be cumulative in the same sense as with pmd-stats-show, so that a user can reset them with the pmd-stats-clear command at any time and chose

Re: [ovs-dev] [PATCH/RFC] bond: add enable-recirc configuration for bond.

Hi Simon, This patch only covers how to prevent recirculation but does not describe how bond selection works in the absence of recirculation. Can you explain? Thanks, Jan > -Original Message- > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev- > boun...@openvswitch.org] On Behalf

[ovs-dev] Compliance of NSH implementation with latest NSH draft

the nsh_flags field to the changed bits in the base header. I believe the we could add the nsh_ttl match field and a corresponding dec_nsh_ttl action at a later stage. What do you think? BR, Jan From: Jan Scheurich Sent: Wednesday, 16 August, 2017 16:05 To: Yang, Yi Y <yi.y.y...@intel.

Re: [ovs-dev] [PATCH v3 1/4] dpif-netdev: Skip EMC lookup/insert for recirc packets

re > > > sent to the classifier directly. > > > An empirical threshold EMC_RECIRCT_NO_INSERT_THRESHOLD - > of 50% - > > > for EMC occupancy is set to trigger this logic. By doing so when > > > EMC utilization exceeds EMC_REC

Re: [ovs-dev] [PATCH v5 1/2] OF support and translation of generic encap and decap

((=,(),...), + * (=,(),...),...) +*/ static char * OVS_WARN_UNUSED_RESULT parse_ENCAP(char *arg, BR, Jan > -Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Tuesday, 08 August, 2017 21:36 > To: Jan Scheurich <jan.scheur...@ericsson.com> > Cc: Yi Yang <

Re: [ovs-dev] [PATCH 2/2] dpif-netdev: Per-port conditional EMC insert.

Hi Ilya, Tuning the per EMC insertion probability per port based on detailed knowledge about the nature of traffic patterns seems a micro-optimization to me, which might be helpful in very controlled setups e.g. in synthetic benchmarks, but very hard to apply in more general use cases, such as

Re: [ovs-dev] [PATCH 1/2] dpif-netdev: Keep latest measured time for PMD thread.

Hi Ilya, I fully agree with storing 'now' as part of the pmd struct instead of passing it around as function arguments. For me struct dp_netdev_pmd_thread is *the* the PMD thread context in dpif-netdev. I don't really see the benefit of creating a sub-struct dp_netdev_pmd_thread_ctx and

Re: [ovs-dev] DPDK Merge Repo

> > and a series we would like to get into 2.8 > > > > netdev-dpdk: Use intermediate queue during packet transmission. Bhanu Jun > > 29/V3 > > netdev: Add netdev_txq_flush function. > > netdev-dpdk: Add netdev_dpdk_txq_flush function. > > netdev-dpdk: Add netdev_dpdk_vhost_txq_flush function. >

Re: [ovs-dev] [PATCH] dpif-netdev: Fix per packet cycles statistics.

Thanks for fixing this, Ilya! It was correct at the time it was committed but very likely to break afterwards. I should have removed the loop from the start and change the way you propose. Acked-by: Jan Scheurich <jan.scheur...@ericsson.com> > -Original Message- > From: I

Re: [ovs-dev] [PATCH v5 1/2] OF support and translation of generic encap and decap

ust, 2017 20:17 > To: Jan Scheurich <jan.scheur...@ericsson.com> > Cc: Yi Yang <yi.y.y...@intel.com>; d...@openvswitch.org; Zoltán Balogh > <zoltan.bal...@ericsson.com> > Subject: Re: [PATCH v5 1/2] OF support and translation of generic encap and > decap > &g

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

> -Original Message- > From: Jiri Benc [mailto:jb...@redhat.com] > Sent: Friday, 11 August, 2017 11:45 > > The context field does not apply to MD type 2. It looks wrong for the > context field to be included in netlink attribute for anything other > than MD type 1. Perhaps it needs to be

Re: [ovs-dev] [PATCH v4 5/5] dpif-netdev: Flush the packets in intermediate queue.

rakash [mailto:bhanuprakash.bodire...@intel.com] > Sent: Friday, 11 August, 2017 15:12 > To: Darrell Ball <db...@vmware.com>; d...@openvswitch.org; Ilya Maximets > <i.maxim...@samsung.com>; Jan Scheurich > <jan.scheur...@ericsson.com>; Eelco Chaudron <echau...@redhat.com> &

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

> From: Jiri Benc [mailto:jb...@redhat.com] > Sent: Friday, 11 August, 2017 12:23 > > On Fri, 11 Aug 2017 10:09:36 +, Jan Scheurich wrote: > > Unless someone can explain to me why the datapath should understand the > > internal structure/format of metadata in pu

Re: [ovs-dev] [PATCH 1/2] dpif-netdev: Keep latest measured time for PMD thread.

> > For me struct dp_netdev_pmd_thread is *the* the PMD thread context in > dpif-netdev. I don't really see the benefit of creating a sub-struct > dp_netdev_pmd_thread_ctx and moving certain data into that. Can you > explain your motivation? > > Hello Jan, > > IMHO all other fields in struct

Re: [ovs-dev] [PATCH v3 0/4] Output packet batching.

Hi Ilya, Thanks for providing these patches. We appreciate a simple/maintainable approach to Tx batching. In our use cases time-based Tx batching across multiple Rx batches provides the biggest value, so we will focus on the complete series including the final RFC patch. BR, Jan >

Re: [ovs-dev] [PATCH RFC v3 4/4] dpif-netdev: Time based output batching.

> This allows to collect packets from more than one RX burst > and send them together with a configurable maximum latency. > > 'other_config:output-max-latency' can be used to configure > time that a packet can wait in output batch for sending. > > Signed-off-by: Ilya Maximets

Re: [ovs-dev] OVS 2.9 Intel Roadmap

What about Billy's patch set for Rx queue prioritization? https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/336001.html Jan > -Original Message- > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev- > boun...@openvswitch.org] On Behalf Of Stokes, Ian > Sent: Monday, 14 August,

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

> From: Jiri Benc [mailto:jb...@redhat.com] > Sent: Monday, 14 August, 2017 09:51 > > On Sun, 13 Aug 2017 21:13:57 +, Jan Scheurich wrote: > > Jiri, I am not too familiar with conventions on the OVS netlink > > interface regarding the handling of vari

Re: [ovs-dev] [PATCH RFC v3 4/4] dpif-netdev: Time based output batching.

> >>From earlier in-house trials we know we need to target flush times of 50 > us or less, so we clearly need better time resolution. Sub-ms timing in PMD > should be based on TSC cycles, which are already kept in the pmd struct. > Could you provide a corresponding patch for performance testing? >

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

> From: Jiri Benc [mailto:jb...@redhat.com] > Sent: Monday, 14 August, 2017 12:48 > > On Mon, 14 Aug 2017 10:35:42 +, Jan Scheurich wrote: > > Is it worth to speculate on how a hypothetical future NSH version > > (with a different Version value in the Base

Re: [ovs-dev] [PATCH RFC v3 4/4] dpif-netdev: Time based output batching.

> > We have tested the effect of turbo mode on TSC and there is none. The > TSC frequency remains at the nominal clock speed, no matter if the core is > clocked down or up. So, I believe for PMD threads (where performance > matters) TSC would be an adequate and efficient clock. > > It's highly

Re: [ovs-dev] Compliance of NSH implementation with latest NSH draft

on this. BR, Jan From: Yang, Yi Y [mailto:yi.y.y...@intel.com] Sent: Thursday, 17 August, 2017 02:17 To: Jan Scheurich <jan.scheur...@ericsson.com>; Zoltán Balogh <zoltan.bal...@ericsson.com> Cc: Ben Pfaff (b...@ovn.org) <b...@ovn.org>; Jiri Benc (jb...@redhat.com) <jb...@

Re: [ovs-dev] [PATCH] nsh: rework NSH netlink keys and actions

Hi Yi, As discussed please adjust the netlink uAPI for NSH as follows: OVS_KEY_ATTR_NSH -- OVS_NSH_KEY_ATTR_BASEmandatory -- OVS_NSH_KEY_ATTR_MD1 conditional: if mdtype=MD1 OVS_ACTION_ATTR_PUSH_NSH -- OVS_NSH_KEY_ATTR_BASEmandatory --

Re: [ovs-dev] [PATCH v3 1/4] dpif-netdev: Skip EMC lookup/insert for recirc packets

    The RSS hash threshold method looks like the only pseudo-random criterion that we can use that produces consistent result for every packet of a flow and does require more information. Of course elephant flows with an unlucky hash value might never get to use the EMC, but that risk we have

Re: [ovs-dev] [PATCH v3 1/4] dpif-netdev: Skip EMC lookup/insert for recirc packets

Hi Antonio, > > Is there a reason to assume that a deterministic selection on some non- > random > > criteria like the recirculation count will on average (over deployments > and > > applications) give a better performance than a random selection? > > [Antonio] > If we consider latency and

Re: [ovs-dev] [PATCH 1/4] Add OF actions for generic encap and decap

n Pfaff [mailto:b...@ovn.org] > Sent: Thursday, 13 July, 2017 19:22 > To: Zoltán Balogh <zoltan.bal...@ericsson.com> > Cc: 'd...@openvswitch.org' <d...@openvswitch.org>; Jan Scheurich > <jan.scheur...@ericsson.com>; Georg Schmuecking > <georg.schmueck...@ericsson.com&

Re: [ovs-dev] [PATCH 1/4] Add OF actions for generic encap and decap

34Z|1|ofp_actions|WARN|set_field ip_dst lacks correct prerequisites ovs-ofctl: actions are invalid with specified match (OFPBAC_MATCH_INCONSISTENT) /Jan > -Original Message- > From: ovs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Jan

Re: [ovs-dev] [PATCH 1/4] Add OF actions for generic encap and decap

Hi Ben, > -Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Tuesday, 11 July, 2017 23:46 > > What is your plan for handling ofpact_check__() with decap actions? > In general a decap() action reveals an inner packet that requires reparsing before any subsequent actions

Re: [ovs-dev] [PATCH 5/6] Generic encap and decap support for NSH

Hi Yi, The following incremental patch drops a packet in the datapath at decap_nsh() rather than aborting if the NSH next protocol field does not match any of the supported values. Normally this should not happen if the next proto field is checked in the ofproto translation, but it feels

Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

These are indeed two different use case. The pure termination of the GTP-u tunnel can be done by adding support for a GTP-u tunnel vport, which should be straightforward now that we have support for L3 tunneling fully upstreamed in in OVS and based on the GTP tunnel support in the Linux kernel.

Re: [ovs-dev] [PATCH 1/6] userspace: Add support for NSH MD1 match fields

Hi Yi, The following incremental makes the formatting of NSH fields in OpenFlow and datapath flows more consistent and easier to use. - Consistently format nsh_spi as hex without leading zeros. - Consistently format MD1 context headers nsh_c without leading zeros. - Format nsh_c

Re: [ovs-dev] [PATCH v4 0/7] Packet type aware pipeline

I think the dropped packets are indeed noise generated by the host kernel when bringing up interfaces and are dependent on system configuration and timing. Dumping datapath flows seems pretty vulnerable to such noise in system tests and it may be hard to create filters that work reliably on all

[ovs-dev] Sync on PTAP, EXT-382 and NSH - Minutes of Meeting Wed 2017-07-12 17:00 CET

NSH series * Yi to include Joe's and Jan's comments and respin NSH v2 series rebased to Generic Encap/Decap v2 * Ben to review NSH series * Jan to call for follow-up meeting next week (Ben in Ireland, UTC+1) BR, Jan -Original Appointment- From: Jan Scheurich

Re: [ovs-dev] [PATCH v2 0/4]tunneling : Improving tunneling performance by avoiding dp recirc.

> -Original Message- > From: Chandran, Sugesh [mailto:sugesh.chand...@intel.com] > Sent: Friday, 14 July, 2017 11:28 > To: Joe Stringer <j...@ovn.org> > Cc: az...@ovn.org; Darrell Ball <db...@vmware.com>; Zoltán Balogh > <zoltan.bal...@ericsson.com>; Jan Sch

Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

> -Original Message- > From: Yang, Yi Y [mailto:yi.y.y...@intel.com] > Sent: Monday, 17 July, 2017 11:18 > To: Jan Scheurich <jan.scheur...@ericsson.com>; Amar Padmanabhan > <amarpadmanab...@fb.com>; Joe Stringer <j...@ovn.org>; > Wieger IJntema <wieg

Re: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink attribute

Hi Eric, Doing the kernel datapath tweak in the ofproto translation logic certainly works but should only be our last resort as it is so ugly. Zoltan will send you an corrected/simplified version of our patch in the next hour or so. It intercepts the flow and mask netlink keys before

Re: [ovs-dev] [PATCH 5/6] Generic encap and decap support for NSH

Hi Yi, The following incremental patch unwildcards the NSH next proto field at translation of a decap() action for an NSH packet. This ensures that a datapath flow only decaps NSH packets of a known encapsulated packet type, avoiding bad suprises when executing decap_nsh action in the

Re: [ovs-dev] [PATCH 0/6] Generic Encap & Decap based NSH implementation

Hi Yi, The following incremental clarifies and cleans up the error handling during translation of encap and decap actions for NSH: - Rephrased the xlate_report_debug() messages when dropping packets during translation of encap/decap actions. - Encap and decap translation error handling

[ovs-dev] Sync on PTAP, EXT-382 and NSH - Wed 2017-07-19 17:00 CET

Hi, Focus on getting the remaining series reviewed and merged for OVS 2.8: 1. Generic Encap/Decap (EXT 382) for Ethernet (Ericsson) 2. L3/PTAP tunnel config for kernel datapath (RedHat) 3. Basic NSH MD1 including Encap/Decap for NSH (Intel) Minutes of previous meeting

[ovs-dev] Sync on PTAP, EXT-382 and NSH - Minutes of Meeting Wed 2017-07-19 17:00 CET

NSH v2 series * Summer vacation: Jan: Jul 21 - Aug 4, Zoltan: Jul 31 - Aug 11. As both of us are off 1st week of August, it would be great if we could finalize Generic encap/decap in July. BR, Jan -Original Appointment- From: Jan Scheurich Sent: Sunday, 18 December

Re: [ovs-dev] [PATCH v2 0/3] basic encap/decap

/3] basic encap/decap > > From: Zoltán Balogh <zoltan.bal...@ericsson.com> > > > This series is a continuation of other patch series initiated by Jan Scheurich > before. These were already applied to the master branch: > - userspace: Support for L3 tunneling >htt

Re: [ovs-dev] [PATCH] packet_type: Force _ETHERTYPE mask in netlink messages

and limit the kernel datapath specialties to a single place in the code. Zoltan has proposed a similar change earlier and will send a corresponding patch soon. BR, Jan > -Original Message- > From: Eric Garver [mailto:e...@erig.me] > Sent: Friday, 30 June, 2017 22:30 > To: J

Re: [ovs-dev] [PATCH 0/3] Output packet batching.

I like this generic approach to collect the packets to be output per port for each Rx batch in dpif-netdev. It is indeed simpler than the approach in [1]. However, [1] originally had a larger scope, namely to buffer packets in an intermediate queue per netdev tx queue *across* multiple rx

[ovs-dev] Sync on PTAP, EXT-382 and NSH - Minutes of Meeting Wed 2017-06-28 14:00 CET

help (e.g. testing MPLS over GRE). * Work on OVS documentation for L3 tunneling, PTAP and encap/decap, NSH. * Jan to call for follow-up meeting in two weeks BR, Jan -Original Appointment----- From: Jan Scheurich Sent: Sunday, 18 December, 2016 15:34 To: J

[ovs-dev] Sync on PTAP, EXT-382 and NSH - Wed 2017-07-12 17:00 CET

Hi, Focus on getting the remaining series reviewed and merged for OVS 2.8: 1. Generic Encap/Decap (EXT 382) for Ethernet (Ericsson) 2. Basic NSH MD1 including Encap/Decap for NSH (Intel) 3. L3/PTAP tunnel config for kernel datapath (RedHat) Thank you, Jan Link to the Google design doc:

[ovs-dev] Sync on PTAP, EXT-382 and NSH: Minutes of meeting Wed 2017-04-26, 17:00 CET

- From: Jan Scheurich Sent: Sunday, 18 December, 2016 15:34 To: Jan Scheurich; Zoltán Balogh; Yang, Yi Y (yi.y.y...@intel.com); Jiri Benc (jb...@redhat.com); Pravin Shelar; Simon Horman (simon.hor...@netronome.com); 'ja...@ovn.org'; 'Ben Pfaff'; 'ben.mackcr...@corsa.com'; d

[ovs-dev] Sync on PTAP, EXT-382 and NSH - Tue 2017-05-09 17:00 CET

Hi, Let's have a look at the status and work out a plan how to accelerate the review and merging in order to achieve the agreed target to upstream these changes in time for OVS 2.8. Thank you, Jan Link to the Google design doc:

[ovs-dev] Sync on PTAP, EXT-382 and NSH - Tue 2017-05-09 17:00 CET

Moved to 2pm CET to accommodate Ben, who is in Boston that week. Perhaps also Yi can join at that time slot. Hi, Let's have a look at the status and work out a plan how to accelerate the review and merging in order to achieve the agreed target to upstream these changes in time for OVS 2.8.

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

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

Re: [ovs-dev] [PATCH v5 1/2] OF support and translation of generic encap and decap

t; From: Yi Yang [mailto:yi.y.y...@intel.com] > Sent: Wednesday, 02 August, 2017 10:04 > To: d...@openvswitch.org > Cc: b...@ovn.org; Jan Scheurich <jan.scheur...@ericsson.com>; Yi Yang > <yi.y.y...@intel.com>; Zoltán Balogh > <zoltan.bal...@ericsson.com> > Subject: [PATCH

Re: [ovs-dev] [patch_v4 2/2] dpif-netdev: Refactor some pmd stats.

Hi Darrell, Please find my specific comments below. I have a general concern for the pmd-stats-show counters: The output refers to the number of processed packets (e.g. processing cycles/pkt etc). But the data actually presented is the total number of *passes of packets through the datapath*.

Re: [ovs-dev] [PATCH] nsh: rework NSH netlink keys and actions

> Jan, MD2 is flexible enough, so we mustn't worry there will be one MDx, it > is very weird to use OVS_NSH_PUSH_ATTR_CONTEXT as sub key of > OVS_KEY_ATTR_NSH. There is no point in introducing OVS_NSH_KEY_ATTR_MD2 as we will never transfer MD2 TLV context headers as explicit fields neither as

Re: [ovs-dev] [PATCH] nsh: rework NSH netlink keys and actions

> > As discussed please adjust the netlink uAPI for NSH as follows: > > > > OVS_KEY_ATTR_NSH > > -- OVS_NSH_KEY_ATTR_BASEmandatory > > -- OVS_NSH_KEY_ATTR_MD1 conditional: if mdtype=MD1 > > > > OVS_ACTION_ATTR_PUSH_NSH > > -- OVS_NSH_KEY_ATTR_BASEmandatory > >

Re: [ovs-dev] [PATCH 0/4] prioritizing latency sensitive traffic

Good discussion. Some thoughts: 1. Prioritizing queues by assigning them to dedicated PMDs is a simple and effective but very crude method, considering that you have to reserve an entire (logical) core for that. So I am all for a more economic and perhaps slightly less deterministic option!

Re: [ovs-dev] [PATCH v2 1/2] nsh: rework NSH netlink keys and actions

Hi Yi, I won't repeat my earlier general comment about OVS_NSH_KEY_ATTR_MD2. Please find other specific comments below. Please also refer to the fixes I proposed in gitlab. /Jan > -Original Message- > From: Yi Yang [mailto:yi.y.y...@intel.com] > Sent: Friday, 18 August, 2017 01:39 >

  1   2   3   4   5   >