From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70051.outbound.protection.outlook.com [40.107.7.51]) by dpdk.org (Postfix) with ESMTP id E5BE41B442 for ; Fri, 4 Jan 2019 08:06:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fdLl6M0AC3CBLLry8kuxiF8DuClBILIMuLOnX4Lgw6A=; b=TsKzeQeCOQTWi4r+q2PGpkLFu0trx7rsfsYI6KiIjp90GXoraO6Wi9m12yh8efmu6PL2sBtLUjwJOmW8I3/Gk07hrBjk/iFWscXdzK9eurT62FSOxZ1zuFDWfaW0elAunGVuuztJb2MDRDbUyXfXavh0yzZx60+5jbfuMkgAjWw= Received: from AM6PR08MB3672.eurprd08.prod.outlook.com (20.177.115.76) by AM6PR08MB3270.eurprd08.prod.outlook.com (52.135.164.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Fri, 4 Jan 2019 07:06:07 +0000 Received: from AM6PR08MB3672.eurprd08.prod.outlook.com ([fe80::25ec:2db7:d268:2b7b]) by AM6PR08MB3672.eurprd08.prod.outlook.com ([fe80::25ec:2db7:d268:2b7b%2]) with mapi id 15.20.1495.005; Fri, 4 Jan 2019 07:06:07 +0000 From: Honnappa Nagarahalli To: Stephen Hemminger CC: Jerin Jacob Kollanukkaran , "david.marchand@redhat.com" , "chaozhu@linux.vnet.ibm.com" , nd , "bruce.richardson@intel.com" , "thomas@monjalon.net" , "dev@dpdk.org" , "Joyce Kong (Arm Technology China)" , "hemant.agrawal@nxp.com" , "Gavin Hu (Arm Technology China)" , nd Thread-Topic: [EXT] [PATCH v3 6/6] spinlock: ticket based to improve fairness Thread-Index: AQHUnZqnw+gdS0Yxz0yLTOe3WzitR6WSJ88AgAA0ZwCAACJSAIAAwbSAgABTEICAClS7UIAAGKQAgAC5QmA= Date: Fri, 4 Jan 2019 07:06:07 +0000 Message-ID: References: <20181227041349.3058-1-gavin.hu@arm.com> <20181227041349.3058-7-gavin.hu@arm.com> <47217c425060db295626c741b9e83f17b63a39bd.camel@marvell.com> <235244228ee4d6b30f268fc72837c6b0790d7037.camel@marvell.com> <20181227154143.7eb56fcc@shemminger-XPS-13-9360> <7918c83453f4d57af83c5b79eae2932a8bf5173f.camel@marvell.com> <20190103115304.7e6547a0@shemminger-XPS-13-9360> In-Reply-To: <20190103115304.7e6547a0@shemminger-XPS-13-9360> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Honnappa.Nagarahalli@arm.com; x-originating-ip: [217.140.103.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR08MB3270; 6:gRf+OPLwrhG+hS8tL4tUSkW9G5Ru6oBT1HEsk0cliTofqaQ+T6oGo9Jk3uwVPd+iDpm85tBBMxJW7nLG54NBUPM35Hxt+Q1m+qPK1Y1Yz4ykrNXHWjwCFVDvzUliZpMBFETDfqnYmu2yF231K5N5uxXwmvnsLEoo2DZ4iJQERIWGRLLzv1x/43MTOJJ7bcAySR2QLBFe+sjrO9QCSzwWtj22VXfJj6yj/2mV+OPWOwBnB+glNAAKYh5ue8Dg44UHCKMrfAyzdbDPDnHXpG0H5OhB2JhbIr/4teI3Ue9L/o/duVfXRuV2lxKzlM1XT3n1nyST2zTmq3qEOlc/c+AM2pKj0V8ntp8H1CtmNHkZVIw/jk2qEgGBITYVy/2aFJSeCQeiUShZouGbngj1Rnp5XFYZqwx6EOQ7bCj/dyUQjZs7ZpZPJA/ypq6rypNIHeYA9Y45IiFvwtPsbyDwkN30sA==; 5:N3Sb50dzGCDn6iJfW85AjHSURph9PMcMBNdRXrWGpJCP/pTu5PP2YZVI8OI1K10BMQJW/uK3+LdOU8jsqKJ9h6ILVYgDINq3Y/t1n8W2ZIMVcZSobsIfWyrV37j7z/tAgZo911nfKiqxVa6wiqX3D4PjgFQyCEBvcblhAhaoc1oQ9TfQJ7iBob8KJYvjrQLCX0mz8tf/sMB8F/dOQuvg5w==; 7:kVL72Ps7donUyMti/zb6xByOVOOa+Ikh2n5Y3KbHBkA4Jf1yw+V+m59FbouSn/aqVPbr0SzZmhB1f45W0cOrzvoeyEem0KT3I9dxuaeIKh0Ebi7WYk1otW8lS0gTf13QWSRkZZFswsmWCtuQjvc0QA== x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-ms-office365-filtering-correlation-id: a724163a-1da8-4266-ecb4-08d67213196a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM6PR08MB3270; x-ms-traffictypediagnostic: AM6PR08MB3270: nodisclaimer: True x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(3231475)(944501520)(52105112)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:AM6PR08MB3270; BCL:0; PCL:0; RULEID:; SRVR:AM6PR08MB3270; x-forefront-prvs: 0907F58A24 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(39860400002)(376002)(346002)(199004)(189003)(8936002)(7696005)(2906002)(105586002)(14454004)(478600001)(8676002)(256004)(14444005)(72206003)(66066001)(476003)(5660300001)(102836004)(9686003)(54906003)(6436002)(33656002)(76176011)(55016002)(106356001)(86362001)(6506007)(11346002)(6916009)(305945005)(74316002)(316002)(6246003)(186003)(97736004)(71200400001)(446003)(71190400001)(3846002)(6116002)(7736002)(93886005)(26005)(4326008)(81156014)(81166006)(25786009)(561944003)(486006)(68736007)(229853002)(99286004)(53936002)(4001150100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3270; H:AM6PR08MB3672.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: gzhOsIutjVH7i7qLLOvfljgZSBTQQy/NA4WGFQ/gZJYqP5hRwDDV1+f2Uc9rXnegyVAzJfLp3AxCen44gfNETf4SPkBezPpx5xRyZAYFOX3zoMBHCKsISvkVm9Z1oQOyD4hotO7lIbx/HyEt7TGFzFu81aTT/aBZiPeu81CiRTu/gk4qVcM7Zc1lF+IIkLVyNiphXb2B7RWOu8C0ST9XWzkK+E6flzKyDe1b48LQJYSXuq2JEQNHMF3WJ130lMt9CV2VGiDh7gAk5XGRvraDZgzGfNI+s+BhltoQ+O1tkg6ckFz42UFR5V5JzPhNJR46 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: a724163a-1da8-4266-ecb4-08d67213196a X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2019 07:06:07.4793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3270 Subject: Re: [dpdk-dev] [EXT] [PATCH v3 6/6] spinlock: ticket based to improve fairness X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 07:06:16 -0000 >=20 > On Thu, 3 Jan 2019 18:35:31 +0000 > Honnappa Nagarahalli wrote: >=20 > > > > > > > > > > > > > > On Thu, 2018-12-27 at 12:13 +0800, Gavin Hu wrote: > > > > > > > > ---------------------------------------------------------- > > > > > > > > - > > > > > > > > ---- > > > > > > > > ---- > > > > > > > > --- > > > > > > > > From: Joyce Kong > > > > > > > > > > > > > > > > The old implementation is unfair, some threads may take > > > > > > > > locks aggressively > > > > > > > > > > > > > > I think, one issue here is x86 and ppc follows traditional > > > > > > > spinlock and > > > > > > > arm64 will be following ticket lock for spinlock implementati= on. > > > > > > > This would change application behaviour on arm64 compared to > > > > > > > x86 > > > > > > > and > > > > > > > ppc. > > > > > > > > > > > > > > How about having a separate API for ticket lock? That would > > > > > > > give, # application choice to use the locking strategy # > > > > > > > application behaviour will be same across all arch. > > > > > > > > > > > > Ok, will do in v4 to have a new named rte_ticket_spinlock API. > > > > > > > > > > I would prefer rte_ticketlock_[lock/unlock/trylock/is_locked] > > > > > name instead of rte_ticket_spinlock_lock etc to reduce the > > > > > length of the API. > > > > > > > > NAK to adding new API for this. > > > > > > > > I want the best possible locks for all applications and all > > > > architectures. > > > > These should be called spinlock so there is no requirement for > > > > application to change to get better performance. Why not just > > > > implement the best algorithm across the board. Yes, this means > > > > collaboration or working on the other guys architecture. > > IMO, the ticket lock should be a separate API. Spin lock (as implemente= d > today) and ticket lock have different characteristics in terms of behavio= r as > well as resources required. For ex: spin lock might be sufficient for a l= ow > contention use case and it requires less number of cache lines. Ticket lo= ck > needs more number of cache lines and might be good for use cases with mor= e > contention. The decision to use spin lock vs ticket lock should be left t= o the > application. >=20 > The problem is that changing applications is hard. Real world application= s are > non-trivial and large. That is while doing things global or at the librar= y level > are easier. > Do you want to go back and evaluate every lock in VPP, NFF-go, OVS, > Tungsten Fabric, .... >=20 > Either a config or runtime option seems best to me. IMO, we should provide both APIs and a config to use ticket lock as the imp= lementation for spin lock. (similar to Jerin's proposal?)