> On Feb 8, 2016, at 5:38 PM, Russell Bryant wrote:
>
> On 02/08/2016 06:18 PM, Justin Pettit wrote:
>>
>> The "shame" comment was meant tongue-in-cheek, but I didn't want to
>> overwhelm the message with smiley faces. Sorry that didn't come
>> through.
>
> Ah, well I'm sorry too. You had in
On Fri, Feb 5, 2016 at 1:30 PM, Russell Bryant wrote:
>
> On 02/05/2016 02:22 AM, Justin Pettit wrote:
> > Joe and I spent some time today discussing our options. This is
> > pretty tricky to get right and most of the options that come
> > immediately to mind have subtle corner cases. We're plan
On Mon, Feb 08, 2016 at 08:46:44PM -0500, Russell Bryant wrote:
> On 02/08/2016 08:45 PM, Russell Bryant wrote:
> > On 02/08/2016 07:52 PM, Ben Pfaff wrote:
> >> Without this additional check, SSET_FOR_EACH is happy to iterate over any
> >> type that has a struct hmap member named 'map'. We have a
On Mon, Feb 08, 2016 at 06:49:33PM -0800, Andy Zhou wrote:
> On Mon, Feb 8, 2016 at 4:52 PM, Ben Pfaff wrote:
>
> > I intend to make further use of this in upcoming commits.
> >
> > Signed-off-by: Ben Pfaff
> > ---
> > lib/util.h | 20 ++--
> > 1 file changed, 18 insertions(+),
On Mon, Feb 08, 2016 at 10:33:39AM -0800, William Tu wrote:
> I spent some time fixing this memory leak but couldn't get it right. Please
> give me some advise how to fix it. Thank you.
I figured it out. It was tricky, and a genuine bug.
See:
http://openvswitch.org/pipermail/dev/2016-Feb
This manifested as a memory leak in test 898 "ofproto-dpif - sFlow packet
sampling - tunnel set", which included an output to a tunnel vport that
doesn't have an implementation of netdev_send().
Reported-by: William Tu
Reported-at: http://openvswitch.org/pipermail/dev/2016-February/065873.html
Si
Andy Zhou wrote on 09/02/2016 01:33:12 AM:
> On Mon, Feb 8, 2016 at 12:43 PM, Liran Schour wrote:
> Andy Zhou wrote on 08/02/2016 09:41:47 PM:
>
> > On Sun, Feb 7, 2016 at 12:08 AM, Liran Schour
wrote:
> > Andy Zhou wrote on 04/02/2016 11:54:06 PM:
> >
> > > On Sun, Jan 31, 2016 at 11:03 P
On Mon, Feb 08, 2016 at 12:25:13PM -0500, Russell Bryant wrote:
> Signed-off-by: Russell Bryant
Thanks. I noticed two other issues while testing this, so I sent
patches for those too:
https://patchwork.ozlabs.org/patch/580625/
https://patchwork.ozlabs.org/patch/580624/
Acked-by:
In particular this ensures that the sub-make that dist-docs runs has the
benefit of any parallelism flags passed into the top-level make.
Signed-off-by: Ben Pfaff
---
Makefile.am | 2 +-
build-aux/dist-docs | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile.a
We shouldn't try to treat every file as Markdown.
Signed-off-by: Ben Pfaff
---
build-aux/dist-docs | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/build-aux/dist-docs b/build-aux/dist-docs
index 1aeefa7..93709c8 100755
--- a/build-aux/dist-docs
+++
That sounds great. I like simple.
On Tue, Feb 09, 2016 at 08:19:57AM +0530, Babu Shanmugam wrote:
> Ben, I tested your solution and it works well. It is in fact simpler than my
> approach. I will squash the other two commits along with this for v2.
>
>
> Thank you,
> Babu
>
> On Tuesday 09 Feb
On Mon, Feb 08, 2016 at 04:52:45PM -0800, Ben Pfaff wrote:
> Some of our data structures derived from hmap use the same member names.
> This means it's possible to confuse them in iteration, e.g. to iterate a
> shash with SIMAP_FOR_EACH. Of course this will crash at runtime, but it
> seems even be
On Mon, Feb 8, 2016 at 4:52 PM, Ben Pfaff wrote:
> Some of our data structures derived from hmap use the same member names.
> This means it's possible to confuse them in iteration, e.g. to iterate a
> shash with SIMAP_FOR_EACH. Of course this will crash at runtime, but it
> seems even better to
On Mon, Feb 8, 2016 at 4:52 PM, Ben Pfaff wrote:
> I intend to make further use of this in upcoming commits.
>
> Signed-off-by: Ben Pfaff
> ---
> lib/util.h | 20 ++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
This is clever! Acked-by: Andy Zhou
>
>
_
Ben, I tested your solution and it works well. It is in fact simpler
than my approach. I will squash the other two commits along with this
for v2.
Thank you,
Babu
On Tuesday 09 February 2016 05:44 AM, Ben Pfaff wrote:
On Mon, Feb 08, 2016 at 03:20:11PM +0530, Babu Shanmugam wrote:
The qos s
On 02/08/2016 08:45 PM, Russell Bryant wrote:
> On 02/08/2016 07:52 PM, Ben Pfaff wrote:
>> Without this additional check, SSET_FOR_EACH is happy to iterate over any
>> type that has a struct hmap member named 'map'. We have a number of these:
>> hmapx, shash, simap, and smap, in addition to sset.
On 02/08/2016 07:52 PM, Ben Pfaff wrote:
> Without this additional check, SSET_FOR_EACH is happy to iterate over any
> type that has a struct hmap member named 'map'. We have a number of these:
> hmapx, shash, simap, and smap, in addition to sset.
>
> I guess another approach would be give each o
On Mon, Feb 8, 2016 at 3:44 PM, Andy Zhou wrote:
>
> Hi, Han,
>
> This is to follow up on the Thursday OVN IRC chat. After the meeting, I
was able replicate the test condition you mentioned where a single
ovsdb-server services 1000 ovsdb-client connections. When there is no
ovsdb transactions g
On 02/08/2016 06:18 PM, Justin Pettit wrote:
>
>> On Feb 8, 2016, at 10:54 AM, Russell Bryant wrote:
>>
>> On 02/08/2016 01:03 PM, Justin Pettit wrote:
>>
>> There are solutions to this problem, but it requires letting a CI system
>> do the merging of patches for you.
>>
>>> The Linux kernel does
Some of our data structures derived from hmap use the same member names.
This means it's possible to confuse them in iteration, e.g. to iterate a
shash with SIMAP_FOR_EACH. Of course this will crash at runtime, but it
seems even better to catch it at compile time.
An alternative would be to use u
I intend to make further use of this in upcoming commits.
Signed-off-by: Ben Pfaff
---
lib/util.h | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/lib/util.h b/lib/util.h
index 0ad75f2..afd8e37 100644
--- a/lib/util.h
+++ b/lib/util.h
@@ -1,5 +1,5 @@
/*
Without this additional check, SSET_FOR_EACH is happy to iterate over any
type that has a struct hmap member named 'map'. We have a number of these:
hmapx, shash, simap, and smap, in addition to sset.
I guess another approach would be give each of these a unique member name,
but the short name 'm
On Mon, Feb 08, 2016 at 03:20:11PM +0530, Babu Shanmugam wrote:
> >>The qos settings are managed using the 'options' fields in the
> >>"Port_Binding" table.
> >>
> >>Signed-off-by: Babu Shanmugam
> >This seems more complicated than necessary. In the
> >SBREC_PORT_BINDING_FOR_EACH loop in binding_
Hi, Han,
This is to follow up on the Thursday OVN IRC chat. After the meeting, I
was able replicate the test condition you mentioned where a single
ovsdb-server services 1000 ovsdb-client connections. When there is no
ovsdb transactions going on,
large number of CPU cycles are used ( on my mach
On Mon, Feb 8, 2016 at 12:43 PM, Liran Schour wrote:
> Andy Zhou wrote on 08/02/2016 09:41:47 PM:
>
> > On Sun, Feb 7, 2016 at 12:08 AM, Liran Schour wrote:
> > Andy Zhou wrote on 04/02/2016 11:54:06 PM:
> >
> > > On Sun, Jan 31, 2016 at 11:03 PM, Liran Schour
> > wrote:
> > > Columns indexin
> On Feb 8, 2016, at 10:54 AM, Russell Bryant wrote:
>
> On 02/08/2016 01:03 PM, Justin Pettit wrote:
>
> There are solutions to this problem, but it requires letting a CI system
> do the merging of patches for you.
>
>> The Linux kernel does something similar.
>> Shame is often a good motivat
On 2016-02-08 11:12, Russell Bryant wrote:
On 02/08/2016 02:00 PM, Ramu Ramamurthy wrote:
Resend (apologies) as the mailer mangled spaces on the patch.
Can you try posting with the git-send-email utility?
I am posting again from a better behaved mailer
_
Currently, conntrack zone-id is assigned to lport by ovn-controller,
but the ovn-controller does not remember what was earlier assigned
to the same lport (possibly in an earlier run across restart).
So, after ovn-controller restart, the zone-ids may get set
inconsistently on lports, resulting in
On 02/08/2016 04:09 PM, Michael wrote:
> I will do this stuff tomorrow, I will take the way ovsdb is started
> using ovs-ctl and refactor the logic in a shared library.
> What I will do for start is make some flags to have the option of
> running dbs separately.
OK thanks,
> I was also thinking
I will do this stuff tomorrow, I will take the way ovsdb is started using
ovs-ctl and refactor the logic in a shared library.
I was also thinking about the database issue for HA and I’m currently thinking
why not to leverage the current ecosystem of distributed dbs.
In specific why not to make
On 02/08/2016 01:02 PM, Michael wrote:
> Title fixed and updated ovn-northd to the new db paths.
Some minor tips on conventions for emailing patches:
When you send another revision, you don't need to specify what changed
in the commit message itself. Notes about what has changed can go after
the
Aha! that makes a lot more sense, but unfortunately, I don't think I'm
grokking the code yet:
1. When using the baseling of SBREC_LOGICAL_FLOW_FOR_EACH, at startup, each
lflow_run pass
handles 12 flows and 12 matches...
2. When I tried using ovsdb_idl_track_add_all and
SBREC_LOGICAL_FLOW_FOR_EACH
Andy Zhou wrote on 08/02/2016 09:41:47 PM:
> On Sun, Feb 7, 2016 at 12:08 AM, Liran Schour wrote:
> Andy Zhou wrote on 04/02/2016 11:54:06 PM:
>
> > On Sun, Jan 31, 2016 at 11:03 PM, Liran Schour
> wrote:
> > Columns indexing is different in ovsdb_row then in ovsdb_monitor_row.
> > We need ma
On 02/08/2016 12:05 PM, Darrell Ball wrote:
> On 2/5/16, 12:23 PM, "Russell Bryant" wrote:
>> I agree with this sort of separation in principle. Some specific
>> examples would help me understand the proposal, though. You mention
>> that this applies to both localnet and gateway cases. Can we l
Hi,
Would you be interested in all *Rackspace *users for your email campaigns?
We can provide you Database from North America, Latin America, EMEA, and
APAC.
*Information Fields* – Name, Title, Email, Phone Numbers, Company Name, and
Company Details like Physical Address, Web Address, Reve
On Sun, Feb 7, 2016 at 12:08 AM, Liran Schour wrote:
> Andy Zhou wrote on 04/02/2016 11:54:06 PM:
>
> > On Sun, Jan 31, 2016 at 11:03 PM, Liran Schour
> wrote:
> > Columns indexing is different in ovsdb_row then in ovsdb_monitor_row.
> > We need mapping between the 2 for condition evaluation.
>
> On Feb 5, 2016, at 7:27 PM, Ben Pfaff wrote:
>
> On Fri, Feb 05, 2016 at 04:41:29PM -0800, Jarno Rajahalme wrote:
>>
>>> On Feb 5, 2016, at 3:30 PM, Ben Pfaff wrote:
>>>
>>> Mirroring is supposed to happen at most once for any destination on a given
>>> packet, so the implementation keeps t
On 02/08/2016 02:00 PM, Ramu Ramamurthy wrote:
>
> Resend (apologies) as the mailer mangled spaces on the patch.
Can you try posting with the git-send-email utility?
--
Russell Bryant
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mai
Resend (apologies) as the mailer mangled spaces on the patch.
Signed-off-by: Ramu Ramamurthy
---
ovn/controller/binding.c | 70
+++-
1 file changed, 63 insertions(+), 7 deletions(-)
diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
On 02/08/2016 01:03 PM, Justin Pettit wrote:
>
>> On Feb 8, 2016, at 9:34 AM, Kavanagh, Mark B
>> wrote:
>>
>>> I think the example that you show is actually a pretty good example of
>>> how quickly we catch problems.
>>
>> Sure. At the same time though, this is a reactive approach, rather than
Currently, conntrack zone-id is assigned to lport by ovn-controller,
but the ovn-controller does not remember what was earlier assigned
to the same lport (possibly in an earlier run across restart).
So, after ovn-controller restart, the zone-ids may get set
inconsistently
on lports, resulting
Hi,
I spent some time fixing this memory leak but couldn't get it right. Please
give me some advise how to fix it. Thank you.
Testcase:
898: ofproto-dpif.at:5172 ofproto-dpif - sFlow packet sampling - tunnel set
Call stacks:
malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
xm
> On Feb 8, 2016, at 9:34 AM, Kavanagh, Mark B
> wrote:
>
>> I think the example that you show is actually a pretty good example of
>> how quickly we catch problems.
>
> Sure. At the same time though, this is a reactive approach, rather than a
> proactive one, which inevitably results in more
Title fixed and updated ovn-northd to the new db paths.
From 9052644fd5ed07583540292fcd0cb5ddc47d633e Mon Sep 17 00:00:00 2001
From: Michael Arnaldi
Date: Mon, 8 Feb 2016 18:56:51 +0100
Subject: [PATCH] Separating ovn nb&sb databases
Signed-off-by: Michael Arnaldi
---
ovn/northd/ovn-northd.c
Hi.
From the ovs design page, bundles only support FlowMod and PortMod
messages, right?
I would like to propose an extension to ovs to support the use of PacketOut
messages in OpenFlow Bundles.
I think PacketOut in bundles would be a good addition because it allows OF
controllers/applications to
I will now revert only in the following points:
> How about using $rundir/ovnnb_db.sock and $rundir/ovnsb_db.sock instead
> of the new directory?
For High Availability we need to have the dbs on a directory that we can easily
share between hosts.
We can do this by default or make it optional us
>
>On Mon, Jan 25, 2016 at 03:15:23PM +, Mark Kavanagh wrote:
>> Current testing guidelines do not take account of two distinct
>> OVS builds:
>>a) 'standard' OVS
>>b) OVS with DPDK integration
>>
>> It is critical that all patches are tested against both builds; if not,
>> there is a s
On Mon, Feb 08, 2016 at 10:34:05AM -0600, Ryan Moats wrote:
> > > I think this is because lflow_run() marks a logical datapath "clean"
> > > after processing any one logical flow in the datapath. I don't know
> why
> > > it does that, but on the face of it it seems wrong.
> > >
> >
> > I'll defini
On 02/08/2016 11:30 AM, Ben Pfaff wrote:
> On Mon, Feb 08, 2016 at 11:21:31AM -0500, Russell Bryant wrote:
>> Fixes: e75291417990 ("ovs-benchmark: Remove.")
>> Signed-off-by: Russell Bryant
>
> Oops, I already applied Ilya's version of this patch.
>
No worries, I didn't see the only patch.
--
There are some relative links designed to work on github. These links
are broken within dist-docs. Adding a symbolic link from the original
filename to the plain text version makes these links work within
dist-docs.
Signed-off-by: Russell Bryant
---
build-aux/dist-docs | 1 +
1 file changed, 1
Signed-off-by: Russell Bryant
---
Documentation/automake.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 9b10df7..5903c22 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -1,4 +1,4 @@
-EXTR
On Wed, Feb 03, 2016 at 02:15:48PM -0600, Ryan Moats wrote:
> I've talked to Kyle about this (as it's becoming a blocker for our scale
> testing) and so I'm willing to spend some time on the following "poor
> man's" approach:
>
> (1) Leave the current ovsdb-server process on the default port to ma
Hi Russell
Thanks for your comments
Darrell
On 2/5/16, 12:23 PM, "Russell Bryant" wrote:
>On 01/29/2016 09:36 PM, Darrell Lu wrote:
>> The following is a proposal regarding how to allow logical
>> and physical endpoint contexts for OVN to stay separated, from
>> a CMS POV.
>>
>> A logical
Russell Bryant wrote on 02/08/2016 10:24:29 AM:
> From: Russell Bryant
> To: Ryan Moats/Omaha/IBM@IBMUS, Michael
> Cc: dev@openvswitch.org
> Date: 02/08/2016 10:24 AM
> Subject: Re: [ovs-dev] [PATCH 1/1] ovn/utilities: Separating OVN NB
> and SBdatabases. Run dbs in separate
>
> On 02/08/2016
The Subject turns into the first line of the commit message. It looks
like it got cut off. It's a bit long anyway. Ideally it should be kept
to 72 characters or so.
On 02/08/2016 10:41 AM, Michael wrote:
> OVN NB & SB DB's should be separated and should run with ovn-ctl start_northd
> / stop_n
"dev" wrote on 02/05/2016 05:09:44 PM:
> From: Ryan Moats/Omaha/IBM@IBMUS
> To: Ben Pfaff
> Cc: dev@openvswitch.org
> Date: 02/05/2016 05:10 PM
> Subject: Re: [ovs-dev] [PATCH] [ovn-controller] [RFC] Poor man's
> lflow incremental processing
> Sent by: "dev"
>
> Ben Pfaff wrote on 02/05/2016
On Mon, Feb 08, 2016 at 11:21:31AM -0500, Russell Bryant wrote:
> Fixes: e75291417990 ("ovs-benchmark: Remove.")
> Signed-off-by: Russell Bryant
Oops, I already applied Ilya's version of this patch.
___
dev mailing list
dev@openvswitch.org
http://openvs
On Mon, Feb 08, 2016 at 10:31:48AM +0300, Ilya Maximets wrote:
> Fixes: e75291417990 ("ovs-benchmark: Remove.")
> Signed-off-by: Ilya Maximets
Applied, thanks.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Quoting Ansis Atteka (ansisatt...@gmail.com):
> On 2 February 2016 at 23:33, Serge Hallyn wrote:
>
> > Quoting Ansis Atteka (ansisatt...@gmail.com):
> > > On 29 January 2016 at 12:10, Serge Hallyn
> > wrote:
> > > > Sorry I've not really had anything to add here, I'm just not familiar
> > > > en
Thanks, applied to master.
On Sun, Feb 07, 2016 at 06:29:32AM +, Ofer Ben-Yacov wrote:
> It does.
>
> Thanks,
> Ofer.
>
> בתאריך יום ו׳, 5 בפבר׳ 2016 ב-22:57 מאת Ben Pfaff <b...@ovn.org>:
>
> > On Thu, Feb 04, 2016 at 09:49:35AM +, Ofer Ben-Yacov wrote:
> > > The tunnel key in d
On 02/08/2016 11:17 AM, Ryan Moats wrote:
> For devstack, we need a few more things:
Context: devstack is an OpenStack development environment. Our OVN
integration pre-dated ovn-ctl, but we'd like to start using it.
> 1) the ability to start and stop the ovsdb processes separate from
> ovn-north
Fixes: e75291417990 ("ovs-benchmark: Remove.")
Signed-off-by: Russell Bryant
---
manpages.mk | 6 --
1 file changed, 6 deletions(-)
diff --git a/manpages.mk b/manpages.mk
index 6141242..bf96e9f 100644
--- a/manpages.mk
+++ b/manpages.mk
@@ -110,12 +110,6 @@ utilities/ovs-appctl.8: \
utiliti
For devstack, we need a few more things:
1) the ability to start and stop the ovsdb processes separate from
ovn-northd, so this patch needs to break them out as separate commands.
2) the logfile settings for vconsole and vfile need to use environment
variables so that we can control their level at
Signed-off-by: Ilya Maximets
---
lib/dpif-netdev.c | 163 +++---
1 file changed, 105 insertions(+), 58 deletions(-)
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index c477f2b..e62f5f6 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@
OVN NB & SB DB's should be separated and should run with ovn-ctl start_northd /
stop_northd
From 351cb81298c5b5393427958d1663cf1d3ddb370b Mon Sep 17 00:00:00 2001
From: Michael Arnaldi
Date: Mon, 8 Feb 2016 16:29:26 +0100
Subject: [PATCH 1/1] ovn/utilities: Separating OVN NB and SB databases. Ru
Since 5f2ccb1c0d3b ("dpif: Allow adding ukeys for same flow by
different pmds.") there is the possibility to reassign queues among
pmd threads without restarting them and deleting the megaflow cache.
So, reconfiguration can be performed without destroying of PMD threads
if pmd-cpu-mask not changed
Resent as a part of patch-set:
http://openvswitch.org/pipermail/dev/2016-February/065846.html
On 04.02.2016 16:41, Ilya Maximets wrote:
> While adding of pmd interface with multiple queues several queues
> may be assigned to one thread and this thread will be reloaded
> one time for each added que
Ilya Maximets (3):
dpif-netdev: Reload each thread only once in do_add_port.
dpif-netdev: Move rxq management into functions.
dpif-netdev: Destroy pmd threads only if pmd-cpu-mask changed.
lib/dpif-netdev.c | 215 +-
1 file changed, 147 in
While adding of pmd interface with multiple queues several queues
may be assigned to one thread and this thread will be reloaded
one time for each added queue.
Signed-off-by: Ilya Maximets
---
lib/dpif-netdev.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/dpif-netdev.c b/l
Aaron Conole writes:
> Apologies for the top post on this one.
>
> I am going to rebase and resubmit this series in 14 - 18 hours. At that
> time I am doing the following:
>
> Changing Kevin and Panu's Cc: lines to ACKs
> Adding:
> Tested-by: RobertX Wojciechowicz
>
> The deltas from v8 to v9 are
>
>Hi Mark,
>
Hi Daniele,
Thanks for the review! Responses inline below.
Cheers,
Mark
>This patch besides adding Jumbo Frame support also cleans up
>the mbuf initialization (by changing the macros, adding
>dpdk_buf_size, and rewriting __ovs_rte_pktmbuf_init), so thanks
>for this. I think it ma
>
>Hi,
>
>Some comments below.
>
Hi Flavio,
Thanks for your review!
I've responded to your comments inline - I've also addressed the cosmetic
changes that you suggested in V3 of the patch.
Thanks again,
Mark
>
>On Mon, 1 Feb 2016 10:18:54 +
>Mark Kavanagh wrote:
>
>> Add support for Ju
The qos settings are managed using the 'options' fields in the
"Port_Binding" table.
Signed-off-by: Babu Shanmugam
This seems more complicated than necessary. In the
SBREC_PORT_BINDING_FOR_EACH loop in binding_run(), I think that we only
need to be able to find the ovsrec_interface associated
> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Friday, February 05, 2016 9:19 PM
> To: Stokes, Ian
> Cc: dev@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH v3] netdev_dpdk.c: Add QoS functionality.
>
> On Thu, Feb 04, 2016 at 09:30:59AM +, Stokes, Ian wrote:
> >
> -Original Message-
> From: Daniele Di Proietto [mailto:diproiet...@vmware.com]
> Sent: Friday, February 05, 2016 9:45 PM
> To: Ben Pfaff; Stokes, Ian
> Cc: dev@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH v3] netdev_dpdk.c: Add QoS functionality.
>
>
>
> On 05/02/2016 13:18, "Ben Pf
75 matches
Mail list logo