From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: spinlock: Move constructor function out of header
	file
Date: Fri, 15 Jul 2016 12:09:54 +0200
Message-ID: <4595749.lyEKuAyhOb@xps13>
References: <20160714132729.27024-1-damarion@cisco.com>
 <6282391.Mg1yxlkp5v@xps13> <15A51CF9-DCB2-4E82-BAF7-5FE2A98AFA3E@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Cc: dev@dpdk.org, Jan Viktorin <viktorin@rehivetech.com>,
 Bruce Richardson <bruce.richardson@intel.com>,
 Konstantin Ananyev <konstantin.ananyev@intel.com>,
 David Marchand <david.marchand@6wind.com>
To: "Damjan Marion (damarion)" <damarion@cisco.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
 by dpdk.org (Postfix) with ESMTP id 1FBA34A65
 for <dev@dpdk.org>; Fri, 15 Jul 2016 12:09:56 +0200 (CEST)
Received: by mail-wm0-f51.google.com with SMTP id f126so19961699wma.1
 for <dev@dpdk.org>; Fri, 15 Jul 2016 03:09:56 -0700 (PDT)
In-Reply-To: <15A51CF9-DCB2-4E82-BAF7-5FE2A98AFA3E@cisco.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2016-07-15 09:54, Damjan Marion:
> So we don=E2=80=99t have much pending beside 2 patches for i40e which=
=20
> Jeff submitted yesterday and they will i guess need to wait for 16.11=
.

Yes these i40e patches will probably have to wait 16.11.

> Only one which I have on my mind is:
>=20
> https://git.fd.io/cgit/vpp/tree/dpdk/dpdk-16.04_patches/0005-Allow-ap=
plications-to-override-rte_delay_us.patch
>=20
> This is big issue for us when running single-core, as some
> drivers tend to call rte_delay_us for a long time, and that is=20
> causing packet drops. I.e. if you do stop/start on one interface
> and you are running BFD on another one, BFD will fail=E2=80=A6
>=20
> Current patch is hack, it basically allows us to override=20
> delay function so we can de-schedule it,
> do some other useful work while waiting for delay to finish
> and then give control back to original function=E2=80=A6
>=20
> Maybe we can fix this by providing a delay callback functionality...

Yes it could be an idea.
Please send a RFC patch.