Re: [ovs-dev] [PATCH 0/8] Linux upstream kernel backports and updates

2018-03-05 Thread Pravin Shelar 
On Mon, Mar 5, 2018 at 8:29 PM, Justin Pettit  wrote:
>
>> On Feb 20, 2018, at 1:16 AM, Justin Pettit  wrote:
>>
>>> On Feb 19, 2018, at 4:30 PM, Pravin Shelar  wrote:
>>>
>>> On Mon, Feb 19, 2018 at 3:23 PM, Justin Pettit  wrote:

> On Feb 19, 2018, at 9:50 AM, Justin Pettit  wrote:
>
>
>> On Feb 16, 2018, at 5:32 PM, Justin Pettit  wrote:
>>
>>
>>> On Feb 16, 2018, at 5:31 PM, Pravin Shelar  wrote:
>>>
>>> Sorry, I misread it, NSH is in 2.9.
>>> I think rest of patches should be easy to backport those patches, I
>>> can work on it tomorrow.
>>
>> If it's not too bad, that would be great.  Thank you very much!
>
> Hi, Pravin.  Have you had a chance to work on this?  I'm just trying to 
> figure out when to release 2.9.  Thanks!

 Don't worry about getting this into branch-2.9.  We had to release 2.9.0 
 due to others' release commitments.  Unless there's a strong need to get 
 it into branch-2.9, we'll just wait for 2.10.0.

>>>
>>> Hi Justin,
>>> I am done with backporting the patches. I need to run sanity tests
>>> with kernel 4.14 and 4.15. I could push it in couple of hours given I
>>> do not find any issues. If it is too late we can push those patches
>>> for later release in 2.9.
>>
>> Thanks, Pravin.  The 2.9.0 release is basically ready other than sending out 
>> the announcement.  You can go ahead and push the changes to branch-2.9 
>> whenever you're ready, and we'll pick them up in the next release.
>
> Hi, Pravin.  I just wanted to check whether you've had a chance to finish 
> this up.
>
right, I have already done with the testing, I forgot to push it.
Thanks for reminding me.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 0/8] Linux upstream kernel backports and updates

2018-03-05 Thread Justin Pettit 

> On Feb 20, 2018, at 1:16 AM, Justin Pettit  wrote:
> 
>> On Feb 19, 2018, at 4:30 PM, Pravin Shelar  wrote:
>> 
>> On Mon, Feb 19, 2018 at 3:23 PM, Justin Pettit  wrote:
>>> 
 On Feb 19, 2018, at 9:50 AM, Justin Pettit  wrote:
 
 
> On Feb 16, 2018, at 5:32 PM, Justin Pettit  wrote:
> 
> 
>> On Feb 16, 2018, at 5:31 PM, Pravin Shelar  wrote:
>> 
>> Sorry, I misread it, NSH is in 2.9.
>> I think rest of patches should be easy to backport those patches, I
>> can work on it tomorrow.
> 
> If it's not too bad, that would be great.  Thank you very much!
 
 Hi, Pravin.  Have you had a chance to work on this?  I'm just trying to 
 figure out when to release 2.9.  Thanks!
>>> 
>>> Don't worry about getting this into branch-2.9.  We had to release 2.9.0 
>>> due to others' release commitments.  Unless there's a strong need to get it 
>>> into branch-2.9, we'll just wait for 2.10.0.
>>> 
>> 
>> Hi Justin,
>> I am done with backporting the patches. I need to run sanity tests
>> with kernel 4.14 and 4.15. I could push it in couple of hours given I
>> do not find any issues. If it is too late we can push those patches
>> for later release in 2.9.
> 
> Thanks, Pravin.  The 2.9.0 release is basically ready other than sending out 
> the announcement.  You can go ahead and push the changes to branch-2.9 
> whenever you're ready, and we'll pick them up in the next release.

Hi, Pravin.  I just wanted to check whether you've had a chance to finish this 
up.

Thanks,

--Justin


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

[ovs-dev] command name of daemon process is null after recover from crash

2018-03-05 Thread Huanle Han 
HI, all
   I find the comm name of daemon process is null after recover from
crash. For example,

1. `ps -ef |grep ovs-vswitchd` : get the ovs-vswitchd pid (not the monitor)
2. `cat /proc/$pid/comm` : see name "ovs-vswitchd"
3. `kill -11 $pid` : make process segfault and crash
4. `ps -ef |grep ovs-vswitchd` : get the new pid
5. `cat /proc/$newpid/comm` : see **nothing**
6. This also effects some tools, such as "top", "lsof"

I believe it's the 'set_subprogram_name("")' in moinitor_daemon()
leads to the problem. But I don't known how to get a correct name
before set.
Do you have any advice?

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

Re: [ovs-dev] [PATCH] tests: Wait for entire trace to hit log.

2018-03-05 Thread William Tu 
On Mon, Mar 5, 2018 at 5:04 PM, Ben Pfaff  wrote:
> "over max translation" appears in the log before the trace, but we're
> checking for the trace immediately after waiting.  This changes the test
> to wait for "packet is dropped" instead, which appears at the end of the
> trace.  This created a race and occasional test failures.
>
> CC: William Tu 
> Fixes: d1ea2cc3de99 ("xlate: auto ofproto trace when recursion too deep")
> Signed-off-by: Ben Pfaff 
> ---
Thanks for the fix!
Acked-by: William Tu 


> I noticed this only after I committed the previous patch, sorry about that!
>
>  tests/ofproto-dpif.at | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
> index fd78c5d9b593..48cbc672d204 100644
> --- a/tests/ofproto-dpif.at
> +++ b/tests/ofproto-dpif.at
> @@ -8487,7 +8487,7 @@ AT_CHECK([ovs-ofctl add-flows br0 flows])
>
>  AT_CHECK([ovs-appctl netdev-dummy/receive br0 
> 'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x1234)'],
>  [0], [stdout])
>
> -OVS_WAIT_UNTIL([grep 'over max translation' ovs-vswitchd.log])
> +OVS_WAIT_UNTIL([grep 'packet is dropped' ovs-vswitchd.log])
>
>  dnl make sure the full ofproto trace dump is present
>  AT_CHECK([grep -c "^ *resubmit" ovs-vswitchd.log],
> --
> 2.16.1
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCHv3 2/2] xlate: add backward resubmit trace log.

2018-03-05 Thread William Tu 
On Mon, Mar 5, 2018 at 5:06 PM, Ben Pfaff  wrote:
> On Wed, Feb 28, 2018 at 04:32:28PM -0800, William Tu wrote:
>> When hitting max translation depth of 64, printing the full
>> ofproto trace is huge and consumes too much log.  The patch
>> adds a short trace log, which prints the top 3 table id and
>> its count of the 64 backward resubmits during the translation.
>>
>> VMWare-BZ: #2054659
>> Signed-off-by: William Tu 
>
> Thanks for the fix!  I applied this to master and branch-2.9.

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

Re: [ovs-dev] [PATCHv3 2/2] xlate: add backward resubmit trace log.

2018-03-05 Thread Ben Pfaff 
On Wed, Feb 28, 2018 at 04:32:28PM -0800, William Tu wrote:
> When hitting max translation depth of 64, printing the full
> ofproto trace is huge and consumes too much log.  The patch
> adds a short trace log, which prints the top 3 table id and
> its count of the 64 backward resubmits during the translation.
> 
> VMWare-BZ: #2054659
> Signed-off-by: William Tu 

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

[ovs-dev] [PATCH] tests: Wait for entire trace to hit log.

2018-03-05 Thread Ben Pfaff 
"over max translation" appears in the log before the trace, but we're
checking for the trace immediately after waiting.  This changes the test
to wait for "packet is dropped" instead, which appears at the end of the
trace.  This created a race and occasional test failures.

CC: William Tu 
Fixes: d1ea2cc3de99 ("xlate: auto ofproto trace when recursion too deep")
Signed-off-by: Ben Pfaff 
---
I noticed this only after I committed the previous patch, sorry about that!

 tests/ofproto-dpif.at | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
index fd78c5d9b593..48cbc672d204 100644
--- a/tests/ofproto-dpif.at
+++ b/tests/ofproto-dpif.at
@@ -8487,7 +8487,7 @@ AT_CHECK([ovs-ofctl add-flows br0 flows])
 
 AT_CHECK([ovs-appctl netdev-dummy/receive br0 
'in_port(1),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x1234)'],
 [0], [stdout])
 
-OVS_WAIT_UNTIL([grep 'over max translation' ovs-vswitchd.log])
+OVS_WAIT_UNTIL([grep 'packet is dropped' ovs-vswitchd.log])
 
 dnl make sure the full ofproto trace dump is present
 AT_CHECK([grep -c "^ *resubmit" ovs-vswitchd.log],
-- 
2.16.1

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

Re: [ovs-dev] [PATCH v1] ofproto-dpif-upcall: fix for segmentation fault

2018-03-05 Thread Justin Pettit 

> On Mar 5, 2018, at 4:09 PM, Ben Pfaff  wrote:
> 
> On Mon, Mar 05, 2018 at 03:04:01PM -0800, Ashish Varma wrote:
>> Added check for NULL pointer on return from xlate_lookup_ofproto
>> function. Access to "ofproto" variable when NULL was causing segmentation
>> fault.
>> 
>> VMware-BZ: #2061914
>> Signed-off-by: Ashish Varma 
>> ---
>> ofproto/ofproto-dpif-upcall.c | 5 +
>> 1 file changed, 5 insertions(+)
>> 
>> diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
>> index 526be77..0079674 100644
>> --- a/ofproto/ofproto-dpif-upcall.c
>> +++ b/ofproto/ofproto-dpif-upcall.c
>> @@ -2129,6 +2129,11 @@ revalidate_ukey__(struct udpif *udpif, const struct 
>> udpif_key *ukey,
>> ofproto = xlate_lookup_ofproto(udpif->backer, , 
>> _in_port);
>> 
>> ofpbuf_clear(odp_actions);
>> +
>> +if (!ofproto) {
>> +goto exit;
>> +}
>> +
>> compose_slow_path(udpif, xoutp, , ctx.flow.in_port.odp_port,
>>   ofp_in_port, odp_actions,
>>   ofproto->up.slowpath_meter_id, >uuid);
> 
> This bug got introduced in commit d39ec23de384 (ofproto-dpif: Don't
> slow-path controller actions.), which introduced the following change.
> The change seems to conscientiously decide that 'ofproto' could no
> longer be NULL, since it removes null tests.  Justin, do you think you
> just overlooked the possibility of null?  Ashish's commit will obviously
> fix the crash; do you think that it is the correct change?

I actually think it was an oversight of the reviewer.  (J'accuse.)

Yes, I agree that was in error.  Thanks for catching it, guys.

--Justin


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

Re: [ovs-dev] [PATCHv3 1/2] xlate: auto ofproto trace when recursion too deep

2018-03-05 Thread Ben Pfaff 
On Wed, Feb 28, 2018 at 04:32:27PM -0800, William Tu wrote:
> Usually ofproto/trace is used to debug the flow translation error.
> When translation error such as recursion too deep or too many resubmit,
> the issue might happen momentary; flows causing the recursion expire
> when users try to debug it.  This patch enables the ofproto trace
> automatically when recursion is too deep or too many resubmit, by
> invoking the translation again, and log the ofproto trace as warnings.
> Since the log will be huge, rate limit to one per minute.
> 
> VMWare-BZ: #2054659
> Signed-off-by: William Tu 

Thank you!

I had to fold in the following because of recently added GCC warnings
that caused a diagnostic for 'rl' having the same name as a different
variable in an outer scope.  I also changed the burst size from 5 to 1
because I am super nervous about this change using a lot of space in
lots (after all, we *know* that this is going to produce at least 64
levels of output).

I applied this to master.  Thanks again!

diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index 9bba16873d2d..9d8818095add 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -1168,10 +1168,10 @@ upcall_xlate(struct udpif *udpif, struct upcall *upcall,
  * these two error types. */
 if (xerr == XLATE_RECURSION_TOO_DEEP ||
 xerr == XLATE_TOO_MANY_RESUBMITS) {
-static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
+static struct vlog_rate_limit rll = VLOG_RATE_LIMIT_INIT(1, 1);
 
 /* This is a huge log, so be conservative. */
-if (!VLOG_DROP_WARN()) {
+if (!VLOG_DROP_WARN()) {
 ds_init();
 ofproto_trace(upcall->ofproto, upcall->flow,
   upcall->packet, NULL, 0, NULL, );
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v1] ofproto-dpif-upcall: fix for segmentation fault

2018-03-05 Thread Ben Pfaff 
On Mon, Mar 05, 2018 at 03:04:01PM -0800, Ashish Varma wrote:
> Added check for NULL pointer on return from xlate_lookup_ofproto
> function. Access to "ofproto" variable when NULL was causing segmentation
> fault.
> 
> VMware-BZ: #2061914
> Signed-off-by: Ashish Varma 
> ---
>  ofproto/ofproto-dpif-upcall.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
> index 526be77..0079674 100644
> --- a/ofproto/ofproto-dpif-upcall.c
> +++ b/ofproto/ofproto-dpif-upcall.c
> @@ -2129,6 +2129,11 @@ revalidate_ukey__(struct udpif *udpif, const struct 
> udpif_key *ukey,
>  ofproto = xlate_lookup_ofproto(udpif->backer, , 
> _in_port);
>  
>  ofpbuf_clear(odp_actions);
> +
> +if (!ofproto) {
> +goto exit;
> +}
> +
>  compose_slow_path(udpif, xoutp, , ctx.flow.in_port.odp_port,
>ofp_in_port, odp_actions,
>ofproto->up.slowpath_meter_id, >uuid);

This bug got introduced in commit d39ec23de384 (ofproto-dpif: Don't
slow-path controller actions.), which introduced the following change.
The change seems to conscientiously decide that 'ofproto' could no
longer be NULL, since it removes null tests.  Justin, do you think you
just overlooked the possibility of null?  Ashish's commit will obviously
fix the crash; do you think that it is the correct change?

@@ -2040,19 +2102,16 @@ revalidate_ukey__(struct udpif *udpif, const struct 
udpif_key *ukey,
 
 if (xoutp->slow) {
 struct ofproto_dpif *ofproto;
 ofp_port_t ofp_in_port;
 
-ofproto = xlate_lookup_ofproto(udpif->backer, ,
-   _in_port);
-uint32_t smid = ofproto ? ofproto->up.slowpath_meter_id : UINT32_MAX;
-uint32_t cmid = ofproto ? ofproto->up.controller_meter_id : UINT32_MAX;
+ofproto = xlate_lookup_ofproto(udpif->backer, , _in_port);
 
 ofpbuf_clear(odp_actions);
 compose_slow_path(udpif, xoutp, , ctx.flow.in_port.odp_port,
-  ofp_in_port, odp_actions, smid, cmid,
-  >uuid);
+  ofp_in_port, odp_actions,
+  ofproto->up.slowpath_meter_id, >uuid);
 }
 
 if (odp_flow_key_to_mask(ukey->mask, ukey->mask_len, _mask, )
 == ODP_FIT_ERROR) {
 goto exit;

Thanks,

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

[ovs-dev] [PATCH] datapath-windows: Do not drop Ip fragments less than MIN_FRAGMENT_SIZE

2018-03-05 Thread Anand Kumar 
Previously ipfragment module would drop any fragments less than
MIN_FRAGMENT_SIZE (400 bytes), which was added to safeguard against the
vulnerability CVE-2000-0305. This check is incorrect, since minimum size
of the Ipfragment is 68 bytes (i.e. max length of Ip Header + 8 bytes of
L4 header). So Ip fragments less than MIN_FRAGMENT_SIZE (400 bytes) is not
guranted to be malformed or illegal.

To guard against security vulnerability CVE-2000-0305, for a given ip
datagram, ipfragments should be dropped only when number of smallest
fragments recieved reaches a certain threshold.

Signed-off-by: Anand Kumar 
---
 datapath-windows/ovsext/IpFragment.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/datapath-windows/ovsext/IpFragment.c 
b/datapath-windows/ovsext/IpFragment.c
index 3d5277a..da9d33a 100644
--- a/datapath-windows/ovsext/IpFragment.c
+++ b/datapath-windows/ovsext/IpFragment.c
@@ -275,10 +275,7 @@ OvsProcessIpv4Fragment(POVS_SWITCH_CONTEXT switchContext,
 offset = ntohs(ipHdr->frag_off) & IP_OFFSET;
 offset <<= 3;
 flags = ntohs(ipHdr->frag_off) & IP_MF;
-/* Only the last fragment can be of smaller size.*/
-if (flags && ntohs(ipHdr->tot_len) < MIN_FRAGMENT_SIZE) {
-return NDIS_STATUS_INVALID_LENGTH;
-}
+
 /*Copy fragment specific fields. */
 fragKey.protocol = ipHdr->protocol;
 fragKey.id = ipHdr->id;
-- 
2.9.3.windows.1

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

[ovs-dev] [PATCH v1] ofproto-dpif-upcall: fix for segmentation fault

2018-03-05 Thread Ashish Varma 
Added check for NULL pointer on return from xlate_lookup_ofproto
function. Access to "ofproto" variable when NULL was causing segmentation
fault.

VMware-BZ: #2061914
Signed-off-by: Ashish Varma 
---
 ofproto/ofproto-dpif-upcall.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index 526be77..0079674 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -2129,6 +2129,11 @@ revalidate_ukey__(struct udpif *udpif, const struct 
udpif_key *ukey,
 ofproto = xlate_lookup_ofproto(udpif->backer, , _in_port);
 
 ofpbuf_clear(odp_actions);
+
+if (!ofproto) {
+goto exit;
+}
+
 compose_slow_path(udpif, xoutp, , ctx.flow.in_port.odp_port,
   ofp_in_port, odp_actions,
   ofproto->up.slowpath_meter_id, >uuid);
-- 
2.7.4

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

Re: [ovs-dev] [PATCH v1 1/2] userspace datapath: Add GTP-U tunnel support

2018-03-05 Thread Jiannan Ouyang 

  On 3/4/18, 6:55 PM, "Yang, Yi"  wrote:
  GTP-C is for control path, so I don't think it makes sense for OVS to
  handle this, in addition GTP-C used different UDP port from GTP-U's, so
  we must have different tunnel ports to handle them respectively. 
 
  I don't know if Jiannan has implemented GTP-C support in kernel data
  path, we can add GTP-C support if it is really needed, but I think it is
  a nice-to-have thing.

No, I didn’t implement GTP-C neither.

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

[ovs-dev] 10 reglas para definir al proveedor ideal

2018-03-05 Thread evaluación de Proveedores 
En línea y en Vivo / Para todo su Equipo con una sola Conexión 

Gestión y evaluación de PROVEEDORES
Trabaje con los mejores
23 de marzo - Online en Vivo - 10:00 a 13:00 y de 15:00 a 18:00Hrs   
 
Seleccione a los mejores y más efectivos proveedores. En esta Capacitación 
Online en Vivo nuestro experto le mostrará la manera más certera de realizar la 
Gestión y Evaluación de sus abastecedores, para reducir costos y optimizar sus 
procesos de producción con calidad y plena satisfacción. Aprenda cómo elegir a 
los mejores proveedores con 10 sencillas reglas para definir al proveedor 
ideal. 

TEMARIO: 

1. Los proveedores y su importancia.
2. Análisis estratégico de la organización y sus proveedores.
3. Métodos de selección de proveedores. 
4. Identificación de productos y compras críticas. 
 
¿Requiere la información a la Brevedad?
responda este email con la palabra: Proveedores.
Junto con los siguientes datos:
Nombre:
Teléfono:
Empresa:
centro telefónico: 018002129393

Lic. Arturo López
Líder de Proyecto
 
¿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

[ovs-dev] A few of your incoming messages has been suspended

2018-03-05 Thread Manit Sangsarp 
Your Messages Has Been Suspended By Microsoft Outlook Team

A few of your incoming messages has been suspended by microsoft verification 
Team because your email box account has not been properly verify. Do verify 
 now to receive your suspended messages now.



Microsoft Outlook Team

Microsoft Outlook Copyright © 2018
















































This email message, including any attachments, is for the sole use of the 
intended recipient(s) and may contain confidential and privileged information. 
Any unauthorized review, use, disclosure or distribution is prohibited. If you 
are not the intended recipient, please contact the sender by reply e-mail and 
destroy all copies of the original message.
E-mail transmission cannot be guaranteed to be secured or error-free as 
information could be intercepted,corrupted, lost, destroyed, arrive late or 
incomplete, or contain viruses, the recipient should check this email and any 
attachments for the presence of viruses. The company is not liable for any 
damage caused by any virus transmitted by this email.[THAI PUBLIC BROADCASTING 
SERVICE (THAI PBS)].

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

[ovs-dev] Your Contract Consignment In New York.

2018-03-05 Thread nicholas water 
Central Bank of Nigeria (C.B.N),
CBN CORPORATE HEADQUARTER,
NNPC Towers, Central Business District,
P.M.B. 190, Garki, Abuja-Nigeria.

Attn: Sir,

After our meetings few days ago, your contract will be paid in our
security firm united states of American in your country since you are
there in USA you have to arrange your self and proceed To New York
meet  with the diplomat who arrived with your contract consignment
that is in charge of your funds payment in USA as soon as i hear from
you by sending your cell phone number, international passport and your
 id card, I will now send you her contact to open a communication with
 her and proceed to receive your consignment in New York your funds
will release to your in your country by diplomatic means.

Waiting to hear from you to enable you proceed and get paid.

Your urgent response is highly expected.

Yours faithfully,


Waiting for your urgent mail.

Mr. Nicholasby Water
Principal Consultant,
Allbond Consulting Financial Advisory.
Abuja Nigeria.
Head of Banking Operations
The Central Bank of Nigeria.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v1 1/2] userspace datapath: Add GTP-U tunnel support

2018-03-05 Thread Joe Stringer 
Ok, thanks for the clarification.

On Mon, 5 Mar 2018, 03:23 Yang, Yi,  wrote:

> On Mon, Mar 05, 2018 at 04:19:58AM +0800, Joe Stringer wrote:
> > ?On 2 March 2018 at 04:32, Yi Yang  wrote:
> > > From: Feng Yang 
> > >
> > > +
> > > +csum = csum_continue(csum, udp, ip_tot_size);
> > > +udp->udp_csum = csum_finish(csum);
> > > +
> > > +if (!udp->udp_csum) {
> > > +udp->udp_csum = htons(0x);
> >
> > What's the motivation behind this?
>
> More comments, this is from the existing ovs code, Feng checked why.
>
> [Feng] According to the standard RFC768,
> https://tools.ietf.org/html/rfc768, I quote, "if the computed  checksum
> is zero,  it is transmitted  as all ones (the equivalent  in one's
> complement  arithmetic)". Actually, netdev_tnl_udp_push_header( ) did
> the same.
>
> >
> > > +}
> > > +}
> > > +
> > > +packet->packet_type = htonl(PT_ETH);
> > > +}
> > > +
> > > +
> > > +int
> > > +netdev_gtpu_build_header(const struct netdev *netdev,
> > > +  struct ovs_action_push_tnl *data,
> > > +  const struct netdev_tnl_build_header_params
> *params)
> > > +{
> > > +struct netdev_vport *dev = netdev_vport_cast(netdev);
> > > +struct netdev_tunnel_config *tnl_cfg;
> > > +struct gtpuhdr *gtph;
> > > +struct udp_header *udp;
> > > +
> > > +/* XXX: RCUfy tnl_cfg. */
> > > +ovs_mutex_lock(>mutex);
> > > +
> > > +tnl_cfg = >tnl_cfg;
> > > +udp = netdev_tnl_ip_build_header(data, params, IPPROTO_UDP);
> > > +udp->udp_dst = tnl_cfg->dst_port;
> > > +udp->udp_src = htons(GTPU_DST_PORT);
> > > +
> > > +if (params->is_ipv6 || params->flow->tunnel.flags &
> FLOW_TNL_F_CSUM) {
> > > +/* Write a value in now to mark that we should compute the
> checksum
> > > + * later. 0x is handy because it is transparent to the
> > > + * calculation. */
> > > +udp->udp_csum = htons(0x);
> >
> > Maybe I missed it, but I didn't see where in this patch that it is
> > computed later due to this value.
> >
>
> This is also from the existing code. udp_build_header is doing same
> thing.
>
> [Feng]  udp_csum is calculated in netdev_gtpu_push_header( ). In
> principle, udp_csum can be arbitrarily set to any two octets except all
> zero, which means transmitter generated no checksum, according to the
> standard, https://tools.ietf.org/html/rfc768.
> We followed what udp_build_header( ) did, by setting udp_csum to 0x.
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] RE

2018-03-05 Thread Nurul Diana Muhammad Shaharudin 


I have been trying to get in touch with you, please contact me directly for 
more details: shirleyle43...@hotmail.com
S L.

Disclaimer http://www.ppj.gov.my/images/email/disclaimer2.htm
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [patch v5 00/11] Userspace datapath: Add fragmentation support.

2018-03-05 Thread Aaron Conole 
Darrell Ball  writes:

> Hi Aaron
>
> I totally missed this response - sorry!
>
> On Thu, Feb 22, 2018 at 10:24 AM, Aaron Conole  wrote:
>
>  Darrell Ball  writes:
>
>  > On Fri, Feb 9, 2018 at 1:35 PM, Aaron Conole  wrote:
>  >
>  >  Hi Darrell,
>  >
>  >  Darrell Ball  writes:
>  >
>  >  > Fragmentation support for userspace datapath conntrack is added; both
>  >  > v4 and v6 are supported. See the patches for additional details.
>  >
>  >  Very pumped about this!
>  >
>  >  I went to start reviewing this, but found out that 04/ didn't apply
>  >  correctly.  No problem, I'll proceed - just figured I'd let you know
>  >  that:
>  >
>  > The merge conflict in NEWS was due to 2 subsequent applies on Feb 6, while
>  > the series was posted on Feb 4.
>
>  Yep.  I've worked around it.
>
>  >1. I'm looking at it :)
>  >
>  > Thanks Aaron
>
>  I have a question on patches 5-7:
>
>Do you think it's worthwhile having these as configuration options in
>the database?
>
>  I can see where it could be considered that they aren't appropriate
>  (after all, the linux fragmentation support is enabled/disabled not via
>  the netlink interface, but by the system administrator outside of the
>  ovs configuration).  On the other hand, from a user perspective it's
>  probably more friendly to have that configuration knob be persistent.
>
>  I think there is value in having the configuration for ipfrag be stored
>  in a database so that each 'restart' doesn't require an extra set of
>  commands be run.  I envision a situation where users have their system
>  configured, restart, and get confused because they have to manually
>  re-enable the configuration.  There are a few ways this could be done
>  (for instance, a post-start script that runs after ovs-ctl), but I think
>  the database might be a useful way of accomplishing that goal - it
>  exists 
>
>  and we use it for dpdk configurations, ex.
>
> For global and interface configuration, yes.
> For flow specific information, the database has very limited usage; notably, 
> there is flow eviction
> policy
>  an ip prefix settings.
>
> I did not opt for using the database here for a few reasons:
>
> 1/ Scripts for starts and restarts will be the same and hence
> the possibility to forget for restart is pretty low;  database
> commands themselves are also run from scripts, for example for interfaces in 
> general and various
> other stuff.

I'm not sure I follow this.  Users, at least in my experience, almost
never deal directly with ovs.  They go through some kind of extra
interface, like neutron/director/ovn/whatever and that deals with all
the headaches of setting up the datapaths, etc.  Usually, they want to
configure everything in the database and then be done with it.  That
lets them query / set using the same interface, and can work remotely
rather than needing permissions and local access.

I just imagine a situation where a customer has a system set up via
OSP/OCP/Kube and vswitchd restarts (for whatever reason... lets say a
crash or something).  When it comes back, the ipfrag flags are cleared.
The customers network may start misbehaving, with the cause unknown
(unless those mechanism start caring about vswitchd process restarts).

Maybe my concern is overblown?  Is there some other mechanism to catch
this case I missed?

> 2/ Using the database, introduces more complexity and dependencies for limited
> gain for something that is usually set once at startup and never changes 
> after that.
>
> I was/am simply leaning towards not using the database here for reasons 
> mentioned above,
> although I did not think it was a clear question one way or the other and I 
> expected the question
> to be mentioned in review. 

I agree that the expectation for this config is 'set and be done'.

>  Something to think on.
>
>  I'm planning on running performance tests this coming week, and will
>  give my patch 3/11 comments then.
>
> Thanks, right now I have not optimized this fully although I identified some
> enhancements.  Fragmentation usage in itself is highly suboptimal and 
> preferred usage is
> either none or a very limited percentage of total pps.

Agreed.  Just want to have a test for when it is turned on vs off.  My
setup got taken up for something else for the moment so I haven't been
able to measure, yet.  Sorry for the delay.

>  Thanks for working on this, Darrell!
>
>  > Darrell
>  >
>  >
>  >2. it'll need at least one more spin (but no need to rush that since
>  >   I'll move myself past the error)
>  >
>  >  Thanks,
>  >  -Aaron
>  >
>  >  > v4->v5: Added a sub-feature to optionally dump fragmentation lists.
>  >  > This is useful for DOS forensics and debugging.
>  >  >
>  >  > The testing coverage was also extended including checking
>  >  > more counters and frag list occupancies.
>  >  >
>  >  > Fixed a few bugs:

Re: [ovs-dev] [patch v5 00/11] Userspace datapath: Add fragmentation support.

2018-03-05 Thread Darrell Ball 
Hi Aaron

I totally missed this response - sorry!

On Thu, Feb 22, 2018 at 10:24 AM, Aaron Conole  wrote:

> Darrell Ball  writes:
>
> > On Fri, Feb 9, 2018 at 1:35 PM, Aaron Conole  wrote:
> >
> >  Hi Darrell,
> >
> >  Darrell Ball  writes:
> >
> >  > Fragmentation support for userspace datapath conntrack is added; both
> >  > v4 and v6 are supported. See the patches for additional details.
> >
> >  Very pumped about this!
> >
> >  I went to start reviewing this, but found out that 04/ didn't apply
> >  correctly.  No problem, I'll proceed - just figured I'd let you know
> >  that:
> >
> > The merge conflict in NEWS was due to 2 subsequent applies on Feb 6,
> while
> > the series was posted on Feb 4.
>
> Yep.  I've worked around it.
>
> >1. I'm looking at it :)
> >
> > Thanks Aaron
>
> I have a question on patches 5-7:
>
>   Do you think it's worthwhile having these as configuration options in
>   the database?
>
> I can see where it could be considered that they aren't appropriate
> (after all, the linux fragmentation support is enabled/disabled not via
> the netlink interface, but by the system administrator outside of the
> ovs configuration).  On the other hand, from a user perspective it's
> probably more friendly to have that configuration knob be persistent.


> I think there is value in having the configuration for ipfrag be stored
> in a database so that each 'restart' doesn't require an extra set of
> commands be run.  I envision a situation where users have their system
> configured, restart, and get confused because they have to manually
> re-enable the configuration.  There are a few ways this could be done
> (for instance, a post-start script that runs after ovs-ctl), but I think
> the database might be a useful way of accomplishing that goal - it
> exists

and we use it for dpdk configurations, ex.


For global and interface configuration, yes.
For flow specific information, the database has very limited usage;
notably, there is flow eviction policy
 an ip prefix settings.

I did not opt for using the database here for a few reasons:

1/ Scripts for starts and restarts will be the same and hence
the possibility to forget for restart is pretty low;  database
commands themselves are also run from scripts, for example for interfaces
in general and various
other stuff.

2/ Using the database, introduces more complexity and dependencies for
limited
gain for something that is usually set once at startup and never changes
after that.

I was/am simply leaning towards not using the database here for reasons
mentioned above,
although I did not think it was a clear question one way or the other and I
expected the question
to be mentioned in review.


>
> Something to think on.


> I'm planning on running performance tests this coming week, and will
> give my patch 3/11 comments then.
>

Thanks, right now I have not optimized this fully although I identified some
enhancements.  Fragmentation usage in itself is highly suboptimal and
preferred usage is
either none or a very limited percentage of total pps.


> Thanks for working on this, Darrell!
>
> > Darrell
> >
> >
> >2. it'll need at least one more spin (but no need to rush that since
> >   I'll move myself past the error)
> >
> >  Thanks,
> >  -Aaron
> >
> >  > v4->v5: Added a sub-feature to optionally dump fragmentation lists.
> >  > This is useful for DOS forensics and debugging.
> >  >
> >  > The testing coverage was also extended including checking
> >  > more counters and frag list occupancies.
> >  >
> >  > Fixed a few bugs:
> >  > 1/ Handle dpdk mempool source restrictions for a batch of
> >  >packets from multiple sources; this also brings in a purge
> >  >frag list function to handle pathological cases of stuck
> frags.
> >  > 2/ ipf_destroy was missing packet frees for frag lists.
> >  > 3/ A setting of CS_INVALID was missing for expired packets -
> >  >I mentioned this earlier for version 4.
> >  >
> >  > Some enhancements and coding standards changes for Patch 3.
> >  >
> >  > v3->v4: Add V6 support to the patches.
> >  > Fix possible race cleanup bug when the user disables
> >  >fragmentation and there are list occupancies, not cleaned
> up
> >  >yet.
> >  > Add missed orig tuple fields for copy from reassembled packet
> >  > to fragments.
> >  > Fix an fragment list increment check - shoiuld have been "> 0"
> >  > rather then "!= 0".
> >  > Fix max frags calculation in case of theoretical corner case.
> >  > Add proper lock annotations.
> >  > Made some other improvements while adding V6 support.
> >  >
> >  > v2->v3: Patch 2 was updated:
> >  > Remove "XXX" todo items by implementing the ones needed,
> >  > including realloc frag_list

[ovs-dev] [PATCH v6.1] tests: Add tests for stopwatch module

2018-03-05 Thread Jakub Sitnicki 
Check if stopwatch module is calculating statistics as expected.

Signed-off-by: Jakub Sitnicki 
---

I forgot to address the clang warning reported by Ben. Please pull this one.

-Jakub

v5 -> v6:
* Use 0 as first sample in tests for trivial input now that the bug with minimum
  calculation is fixed.
* Address clang warning about missing field initializers.

 lib/stopwatch.c|   2 +-
 tests/automake.mk  |   3 +-
 tests/library.at   |   5 ++
 tests/test-stopwatch.c | 195 +
 4 files changed, 203 insertions(+), 2 deletions(-)
 create mode 100644 tests/test-stopwatch.c

diff --git a/lib/stopwatch.c b/lib/stopwatch.c
index 185f4a32f..ce48e3981 100644
--- a/lib/stopwatch.c
+++ b/lib/stopwatch.c
@@ -245,7 +245,7 @@ stopwatch_get_stats_protected(const char *name,
 return false;
 }

-stats->count = perf->samples;
+stats->count = perf->n_samples;
 stats->unit = perf->units;
 stats->max = perf->max;
 stats->min = perf->min;
diff --git a/tests/automake.mk b/tests/automake.mk
index 18698ebc3..4d43af0a5 100644
--- a/tests/automake.mk
+++ b/tests/automake.mk
@@ -364,7 +364,8 @@ tests_ovstest_SOURCES = \
tests/test-uuid.c \
tests/test-bitmap.c \
tests/test-vconn.c \
-   tests/test-aa.c
+   tests/test-aa.c \
+   tests/test-stopwatch.c

 if !WIN32
 tests_ovstest_SOURCES += \
diff --git a/tests/library.at b/tests/library.at
index 5efbfbb7c..1e81a80be 100644
--- a/tests/library.at
+++ b/tests/library.at
@@ -251,3 +251,8 @@ AT_CLEANUP
 AT_SETUP([rcu])
 AT_CHECK([ovstest test-rcu-quiesce], [0], [])
 AT_CLEANUP
+
+AT_SETUP([stopwatch module])
+AT_CHECK([ovstest test-stopwatch], [0], [..
+], [ignore])
+AT_CLEANUP
diff --git a/tests/test-stopwatch.c b/tests/test-stopwatch.c
new file mode 100644
index 0..1270cd936
--- /dev/null
+++ b/tests/test-stopwatch.c
@@ -0,0 +1,195 @@
+/*
+ * Copyright (c) 2018 Red Hat, Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at:
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include 
+#undef NDEBUG
+#include "stopwatch.h"
+#include 
+#include 
+#include 
+#include "ovstest.h"
+#include "util.h"
+
+#define MAX_SAMPLES 100
+#define UNIT SW_MS
+
+struct test_data {
+const char *name;
+unsigned long long samples[MAX_SAMPLES];
+size_t num_samples;
+struct stopwatch_stats expected_stats;
+};
+
+static struct test_data data_sets[] = {
+{
+.name = "1-interval-zero-length",
+.samples = { 0, 0 },
+.num_samples = 2,
+.expected_stats = {
+.count = 1,
+.unit = UNIT,
+.max = 0,
+.min = 0,
+.pctl_95 = 0,
+.ewma_50 = 0,
+.ewma_1 = 0,
+},
+},
+{
+.name = "1-interval-unit-length",
+.samples = { 0, 1 },
+.num_samples = 2,
+.expected_stats = {
+.count = 1,
+.unit = UNIT,
+.max = 1,
+.min = 1,
+.pctl_95 = 0,
+.ewma_50 = 1,
+.ewma_1 = 1,
+},
+},
+{
+.name = "10-intervals-unit-length",
+.samples = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 },
+.num_samples = 11,
+.expected_stats = {
+.count = 10,
+.unit = UNIT,
+.max = 1,
+.min = 1,
+.pctl_95 = 1,
+.ewma_50 = 1,
+.ewma_1 = 1,
+},
+},
+{
+.name = "10-intervals-linear-growth",
+.samples = { 1, 2, 4, 7, 11, 16, 22, 29, 37, 46, 56 },
+.num_samples = 11,
+.expected_stats = {
+.count = 10,
+.unit = UNIT,
+.max = 10,
+.min = 1,
+.pctl_95 = 10.0,
+.ewma_50 = 9.0,
+.ewma_1 = 1.4,
+},
+},
+{
+.name = "60-intervals-unit-length",
+.samples = { 1,  2,  3,  4,  5,  6,  7,  8,  9, 10,
+11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
+21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
+31, 32, 33, 34, 35, 36, 37, 38, 39, 40,
+41, 42, 43, 44, 45, 46, 47, 48, 49, 50,
+51, 52, 53, 54, 55, 56, 57, 58, 59, 60,
+61, },
+.num_samples = 61,
+.expected_stats = {
+.count = 60,
+.unit = UNIT,
+.max = 1,
+.min = 1,
+.pctl_95 = 1,
+

[ovs-dev] [PATCH v6] tests: Add tests for stopwatch module

2018-03-05 Thread Jakub Sitnicki 
Check if stopwatch module is calculating statistics as expected.

Signed-off-by: Jakub Sitnicki 
---
Hey Mark,

I've removed the remaining FIXME's from the tests.

Could you pull this patch into the next iteration?

-Jakub

v5 -> v6:
* Use 0 as first sample in tests for trivial input now that the bug with minimum
  calculation is fixed.

 lib/stopwatch.c|   2 +-
 tests/automake.mk  |   3 +-
 tests/library.at   |   5 ++
 tests/test-stopwatch.c | 195 +
 4 files changed, 203 insertions(+), 2 deletions(-)
 create mode 100644 tests/test-stopwatch.c

diff --git a/lib/stopwatch.c b/lib/stopwatch.c
index 185f4a32f..ce48e3981 100644
--- a/lib/stopwatch.c
+++ b/lib/stopwatch.c
@@ -245,7 +245,7 @@ stopwatch_get_stats_protected(const char *name,
 return false;
 }

-stats->count = perf->samples;
+stats->count = perf->n_samples;
 stats->unit = perf->units;
 stats->max = perf->max;
 stats->min = perf->min;
diff --git a/tests/automake.mk b/tests/automake.mk
index 18698ebc3..4d43af0a5 100644
--- a/tests/automake.mk
+++ b/tests/automake.mk
@@ -364,7 +364,8 @@ tests_ovstest_SOURCES = \
tests/test-uuid.c \
tests/test-bitmap.c \
tests/test-vconn.c \
-   tests/test-aa.c
+   tests/test-aa.c \
+   tests/test-stopwatch.c

 if !WIN32
 tests_ovstest_SOURCES += \
diff --git a/tests/library.at b/tests/library.at
index 5efbfbb7c..1e81a80be 100644
--- a/tests/library.at
+++ b/tests/library.at
@@ -251,3 +251,8 @@ AT_CLEANUP
 AT_SETUP([rcu])
 AT_CHECK([ovstest test-rcu-quiesce], [0], [])
 AT_CLEANUP
+
+AT_SETUP([stopwatch module])
+AT_CHECK([ovstest test-stopwatch], [0], [..
+], [ignore])
+AT_CLEANUP
diff --git a/tests/test-stopwatch.c b/tests/test-stopwatch.c
new file mode 100644
index 0..b49641cd7
--- /dev/null
+++ b/tests/test-stopwatch.c
@@ -0,0 +1,195 @@
+/*
+ * Copyright (c) 2018 Red Hat, Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at:
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include 
+#undef NDEBUG
+#include "stopwatch.h"
+#include 
+#include 
+#include 
+#include "ovstest.h"
+#include "util.h"
+
+#define MAX_SAMPLES 100
+#define UNIT SW_MS
+
+struct test_data {
+const char *name;
+unsigned long long samples[MAX_SAMPLES];
+size_t num_samples;
+struct stopwatch_stats expected_stats;
+};
+
+static struct test_data data_sets[] = {
+{
+.name = "1-interval-zero-length",
+.samples = { 0, 0 },
+.num_samples = 2,
+.expected_stats = {
+.count = 1,
+.unit = UNIT,
+.max = 0,
+.min = 0,
+.pctl_95 = 0,
+.ewma_50 = 0,
+.ewma_1 = 0,
+},
+},
+{
+.name = "1-interval-unit-length",
+.samples = { 0, 1 },
+.num_samples = 2,
+.expected_stats = {
+.count = 1,
+.unit = UNIT,
+.max = 1,
+.min = 1,
+.pctl_95 = 0,
+.ewma_50 = 1,
+.ewma_1 = 1,
+},
+},
+{
+.name = "10-intervals-unit-length",
+.samples = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 },
+.num_samples = 11,
+.expected_stats = {
+.count = 10,
+.unit = UNIT,
+.max = 1,
+.min = 1,
+.pctl_95 = 1,
+.ewma_50 = 1,
+.ewma_1 = 1,
+},
+},
+{
+.name = "10-intervals-linear-growth",
+.samples = { 1, 2, 4, 7, 11, 16, 22, 29, 37, 46, 56 },
+.num_samples = 11,
+.expected_stats = {
+.count = 10,
+.unit = UNIT,
+.max = 10,
+.min = 1,
+.pctl_95 = 10.0,
+.ewma_50 = 9.0,
+.ewma_1 = 1.4,
+},
+},
+{
+.name = "60-intervals-unit-length",
+.samples = { 1,  2,  3,  4,  5,  6,  7,  8,  9, 10,
+11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
+21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
+31, 32, 33, 34, 35, 36, 37, 38, 39, 40,
+41, 42, 43, 44, 45, 46, 47, 48, 49, 50,
+51, 52, 53, 54, 55, 56, 57, 58, 59, 60,
+61, },
+.num_samples = 61,
+.expected_stats = {
+.count = 60,
+.unit = UNIT,
+.max = 1,
+.min = 1,
+.pctl_95 = 1,
+.ewma_50 = 1,
+

Re: [ovs-dev] [PATCH v5 2/5] Measure timing of ovn-controller loop.

2018-03-05 Thread Jakub Sitnicki 
On Fri, Mar 02, 2018 at 11:08 PM GMT, Mark Michelson wrote:
> This modifies ovn-controller to measure the amount of time it takes to
> detect a change in the southbound database and generate the resulting
> flow table. This may require multiple iterations of the ovn-controller
> loop.
>
> The statistics can be queried using:
>
> ovs-appctl -t ovn-controller stopwatch/show ovn-controller-loop
>
> The statistics can be reset using:
>
> ovs-appctl -t ovn-controller stopwatch/reset ovn-controller-loop
>
> Signed-off-by: Mark Michelson 
> ---
>  ovn/controller/ovn-controller.c | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/ovn/controller/ovn-controller.c b/ovn/controller/ovn-controller.c
> index 7592bda25..9ecd859df 100644
> --- a/ovn/controller/ovn-controller.c
> +++ b/ovn/controller/ovn-controller.c
> @@ -57,6 +57,9 @@
>  #include "stream.h"
>  #include "unixctl.h"
>  #include "util.h"
> +#include "timeval.h"
> +#include "timer.h"
> +#include "stopwatch.h"
>  
>  VLOG_DEFINE_THIS_MODULE(main);
>  
> @@ -67,6 +70,8 @@ static unixctl_cb_func inject_pkt;
>  #define DEFAULT_BRIDGE_NAME "br-int"
>  #define DEFAULT_PROBE_INTERVAL_MSEC 5000
>  
> +#define CONTROLLER_LOOP_stopwatch_NAME "ovn-controller-loop"

This mixed case name like a fall-out from the rename.

-Jakub

> +
>  static void update_probe_interval(struct controller_ctx *,
>const char *ovnsb_remote);
>  static void parse_options(int argc, char *argv[]);
> @@ -639,8 +644,10 @@ main(int argc, char *argv[])
>  unixctl_command_register("inject-pkt", "MICROFLOW", 1, 1, inject_pkt,
>   _pkt);
>  
> +stopwatch_create(CONTROLLER_LOOP_stopwatch_NAME, SW_MS);
>  /* Main loop. */
>  exiting = false;
> +unsigned int our_seqno = 0;
>  while (!exiting) {
>  /* Check OVN SB database. */
>  char *new_ovnsb_remote = get_ovnsb_remote(ovs_idl_loop.idl);
> @@ -659,6 +666,12 @@ main(int argc, char *argv[])
>  .ovnsb_idl_txn = ovsdb_idl_loop_run(_idl_loop),
>  };
>  
> +if (our_seqno != ovsdb_idl_get_seqno(ctx.ovnsb_idl)) {
> +stopwatch_start(CONTROLLER_LOOP_stopwatch_NAME,
> +time_msec());
> +our_seqno = ovsdb_idl_get_seqno(ctx.ovnsb_idl);
> +}
> +
>  update_probe_interval(, ovnsb_remote);
>  
>  update_ssl_config(ctx.ovs_idl);
> @@ -728,6 +741,9 @@ main(int argc, char *argv[])
>  ofctrl_put(_table, _ct_zones,
> get_nb_cfg(ctx.ovnsb_idl));
>  
> +stopwatch_stop(CONTROLLER_LOOP_stopwatch_NAME,
> +   time_msec());
> +
>  hmap_destroy(_table);
>  }
>  if (ctx.ovnsb_idl_txn) {
> @@ -792,6 +808,7 @@ main(int argc, char *argv[])
>  ofctrl_wait();
>  pinctrl_wait();
>  }
> +
>  ovsdb_idl_loop_commit_and_wait(_idl_loop);
>  
>  if (ovsdb_idl_loop_commit_and_wait(_idl_loop) == 1) {

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

[ovs-dev] [PATCH v6] Configurable Link State Change (LSC) detection mode

2018-03-05 Thread Róbert Mulik 
It is possible to change LSC detection mode to polling or interrupt mode
for DPDK interfaces. The default is polling mode. To set interrupt mode,
option dpdk-lsc-interrupt has to be set to true.

In polling mode more processor time is needed, since the OVS repeatedly reads
the link state with a short period. It can lead to packet loss for certain
systems.

In interrupt mode the hardware itself triggers an interrupt when link state
change happens, so less processing time needs for the OVS.

For detailed description and usage see the dpdk install documentation.

Signed-off-by: Robert Mulik 
---
v5 -> v6:
- DPDK install documentation updated.
- Status of lsc_interrupt_mode of DPDK interfaces can be read by command
  ovs-appctl dpif/show.
- It was suggested to check if the HW supports interrupt mode, but it is not
  possible to do without DPDK code change, so it is skipped from this patch.
---
 Documentation/intro/install/dpdk.rst | 33 +
 lib/netdev-dpdk.c| 24 ++--
 vswitchd/vswitch.xml | 17 +
 3 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/Documentation/intro/install/dpdk.rst 
b/Documentation/intro/install/dpdk.rst
index ed358d5..eb1bc7b 100644
--- a/Documentation/intro/install/dpdk.rst
+++ b/Documentation/intro/install/dpdk.rst
@@ -628,6 +628,39 @@ The average number of packets per output batch can be 
checked in PMD stats::

 $ ovs-appctl dpif-netdev/pmd-stats-show

+Link State Change (LSC) detection configuration
+~~~
+
+There are two methods to get the information when Link State Change (LSC)
+happens on a network interface: by polling or interrupt.
+
+With the polling method, the main process checks the link state on a
+fixed interval. This fixed interval determines how fast a link change is
+detected.
+
+If interrupts are used to get LSC information, the hardware itself triggers
+an interrupt when link state change happens, the interrupt thread wakes up
+from sleep, updates the information, and goes back to sleep mode. When no link
+state change happens (most of the time), the thread remains in sleep mode and
+doesn`t use processor time at all. The disadvantage of this method is that
+when an interrupt happens, the processor has to handle it immediately, so it
+puts the currently running process to background, handles the interrupt, and
+takes the background process back.
+
+Note that not all PMD drivers support LSC interrupts.
+
+The default configuration is polling mode. To set interrupt mode, option
+``dpdk-lsc-interrupt`` has to be set to ``true``.
+
+Command to set interrupt mode for a specific interface::
+$ ovs-vsctl set interface  options:dpdk-lsc-interrupt=true
+
+Command to set polling mode for a specific interface::
+$ ovs-vsctl set interface  options:dpdk-lsc-interrupt=false
+
+Command to remove ``dpdk-lsc-interrupt`` option::
+$ ovs-vsctl remove interface  options dpdk-lsc-interrupt
+
 Limitations
 

diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 94fb163..e2794e8 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -433,6 +433,12 @@ struct netdev_dpdk {
 /* DPDK-ETH hardware offload features,
  * from the enum set 'dpdk_hw_ol_features' */
 uint32_t hw_ol_features;
+
+/* Properties for link state change detection mode.
+ * If lsc_interrupt_mode is set to false, poll mode is used,
+ * otherwise interrupt mode is used. */
+bool requested_lsc_interrupt_mode;
+bool lsc_interrupt_mode;
 );

 PADDED_MEMBERS(CACHE_LINE_SIZE,
@@ -686,12 +692,14 @@ dpdk_watchdog(void *dummy OVS_UNUSED)
 }

 static int
-dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev, int n_rxq, int n_txq)
+dpdk_eth_dev_port_config(struct netdev_dpdk *dev, int n_rxq, int n_txq)
 {
 int diag = 0;
 int i;
 struct rte_eth_conf conf = port_conf;

+conf.intr_conf.lsc = dev->lsc_interrupt_mode;
+
 /* For some NICs (e.g. Niantic), scatter_rx mode needs to be explicitly
  * enabled. */
 if (dev->mtu > ETHER_MTU) {
@@ -801,7 +809,7 @@ dpdk_eth_dev_init(struct netdev_dpdk *dev)
 n_rxq = MIN(info.max_rx_queues, dev->up.n_rxq);
 n_txq = MIN(info.max_tx_queues, dev->up.n_txq);

-diag = dpdk_eth_dev_queue_setup(dev, n_rxq, n_txq);
+diag = dpdk_eth_dev_port_config(dev, n_rxq, n_txq);
 if (diag) {
 VLOG_ERR("Interface %s(rxq:%d txq:%d) configure error: %s",
  dev->up.name, n_rxq, n_txq, rte_strerror(-diag));
@@ -897,6 +905,7 @@ common_construct(struct netdev *netdev, dpdk_port_t port_no,
 dev->flags = 0;
 dev->requested_mtu = ETHER_MTU;
 dev->max_packet_len = MTU_TO_FRAME_LEN(dev->mtu);
+dev->requested_lsc_interrupt_mode = 0;
 ovsrcu_index_init(>vid, -1);
 dev->vhost_reconfigured = false;
 dev->attached = false;
@@ -1320,6 +1329,8 @@

Re: [ovs-dev] [PATCH] AppVeyor: Add Win10 compilation to the build

2018-03-05 Thread aserdean 
-Mesaj original-
De la: ovs-dev-boun...@openvswitch.org  În
numele Shashank Ram
Trimis: Monday, March 5, 2018 6:44 AM
Către: Alin Gabriel Serdean 
Cc: d...@openvswitch.org
Subiect: Re: [ovs-dev] [PATCH] AppVeyor: Add Win10 compilation to the build

On Fri, Mar 2, 2018 at 3:32 PM, Alin Gabriel Serdean 
wrote:

> People from AppVeyor are nice and included the Windows 10 DDK (driver 
> development kit).
>
> This patch allows AppVeyor to compile the Win10 target.
>
> Signed-off-by: Alin Gabriel Serdean 
> ---
>  appveyor.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/appveyor.yml b/appveyor.yml index da31764c1..49fcae4b5 
> 100644
> --- a/appveyor.yml
> +++ b/appveyor.yml
> @@ -41,6 +41,6 @@ build_script:
>  - C:\MinGW\msys\1.0\bin\bash -lc "cp 
> /c/pthreads-win32/Pre-built.2/dll/x86/*.dll
> /c/openvswitch/."
>  - C:\MinGW\msys\1.0\bin\bash -lc "mv /bin/link.exe /bin/link_copy.exe"
>  - C:\MinGW\msys\1.0\bin\bash -lc "cd /c/openvswitch && ./boot.sh"
> -- C:\MinGW\msys\1.0\bin\bash -lc "cd /c/openvswitch && ./configure 
> CC=build-aux/cccl LD=\"`which link`\" LIBS=\"-lws2_32 -liphlpapi 
> -lwbemuuid
> -lole32 -loleaut32\" --with-pthread=C:/pthreads-win32/Pre-built.2
> --with-openssl=C:/OpenSSL-Win32 --with-vstudiotarget=\"Debug\"
> --with-vstudiotargetver=\"Win8,Win8.1\""
> +- C:\MinGW\msys\1.0\bin\bash -lc "cd /c/openvswitch && ./configure
> CC=build-aux/cccl LD=\"`which link`\" LIBS=\"-lws2_32 -liphlpapi 
> -lwbemuuid
> -lole32 -loleaut32\" --with-pthread=C:/pthreads-win32/Pre-built.2
> --with-openssl=C:/OpenSSL-Win32 --with-vstudiotarget=\"Debug\"
>  - C:\MinGW\msys\1.0\bin\bash -lc "cd /c/openvswitch && make"
>  - C:\MinGW\msys\1.0\bin\bash -lc "cd /c/openvswitch && make 
> datapath_windows_analyze"
> --
> 2.16.1.windows.1
>
> ___
>

Acked-by: Shashank Ram 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[Alin Serdean] Thanks for the review! Applied on master.

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

Re: [ovs-dev] [PATCH v1 1/2] userspace datapath: Add GTP-U tunnel support

2018-03-05 Thread Yang, Yi 
On Mon, Mar 05, 2018 at 04:19:58AM +0800, Joe Stringer wrote:
> ?On 2 March 2018 at 04:32, Yi Yang  wrote:
> > From: Feng Yang 
> >
> > +
> > +csum = csum_continue(csum, udp, ip_tot_size);
> > +udp->udp_csum = csum_finish(csum);
> > +
> > +if (!udp->udp_csum) {
> > +udp->udp_csum = htons(0x);
> 
> What's the motivation behind this?

More comments, this is from the existing ovs code, Feng checked why.

[Feng] According to the standard RFC768,
https://tools.ietf.org/html/rfc768, I quote, "if the computed  checksum
is zero,  it is transmitted  as all ones (the equivalent  in one's
complement  arithmetic)". Actually, netdev_tnl_udp_push_header( ) did
the same.

> 
> > +}
> > +}
> > +
> > +packet->packet_type = htonl(PT_ETH);
> > +}
> > +
> > +
> > +int
> > +netdev_gtpu_build_header(const struct netdev *netdev,
> > +  struct ovs_action_push_tnl *data,
> > +  const struct netdev_tnl_build_header_params 
> > *params)
> > +{
> > +struct netdev_vport *dev = netdev_vport_cast(netdev);
> > +struct netdev_tunnel_config *tnl_cfg;
> > +struct gtpuhdr *gtph;
> > +struct udp_header *udp;
> > +
> > +/* XXX: RCUfy tnl_cfg. */
> > +ovs_mutex_lock(>mutex);
> > +
> > +tnl_cfg = >tnl_cfg;
> > +udp = netdev_tnl_ip_build_header(data, params, IPPROTO_UDP);
> > +udp->udp_dst = tnl_cfg->dst_port;
> > +udp->udp_src = htons(GTPU_DST_PORT);
> > +
> > +if (params->is_ipv6 || params->flow->tunnel.flags & FLOW_TNL_F_CSUM) {
> > +/* Write a value in now to mark that we should compute the checksum
> > + * later. 0x is handy because it is transparent to the
> > + * calculation. */
> > +udp->udp_csum = htons(0x);
> 
> Maybe I missed it, but I didn't see where in this patch that it is
> computed later due to this value.
> 

This is also from the existing code. udp_build_header is doing same
thing.

[Feng]  udp_csum is calculated in netdev_gtpu_push_header( ). In
principle, udp_csum can be arbitrarily set to any two octets except all
zero, which means transmitter generated no checksum, according to the
standard, https://tools.ietf.org/html/rfc768.
We followed what udp_build_header( ) did, by setting udp_csum to 0x. 

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

Re: [ovs-dev] [PATCH v1 1/2] userspace datapath: Add GTP-U tunnel support

2018-03-05 Thread Yang, Yi 
On Sun, Mar 04, 2018 at 09:59:18PM -0800, Joe Stringer wrote:
> On 4 March 2018 at 19:58, Yang, Yi  wrote:
> > On Sun, Mar 04, 2018 at 07:40:49PM -0800, Joe Stringer wrote:
> >> On 4 March 2018 at 18:48, Yang, Yi  wrote:
> >> > On Mon, Mar 05, 2018 at 04:19:58AM +0800, Joe Stringer wrote:
> >> >> ?On 2 March 2018 at 04:32, Yi Yang  wrote:
> 
> > By the way, Feng said the existing GTP kernel implementation also didn't
> > implement GTP-C and didn't handle other optional flag bits.
> 
> Ah, okay. The thing I was thinking of was the way to configure a GTP
> socket to forward signalling traffic to a userspace process for
> handling:
> 
> https://www.kernel.org/doc/Documentation/networking/gtp.txt
>

Yeah, this is just why we are to handle signaling message here, we can
add Openflow rule to forward such message to local or remote userspace
process, per Feng's explanation, this signaling message will be output
to the GTP-U tunnel with different destination IP.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev