From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-oln040092013015.outbound.protection.outlook.com [40.92.13.15]) by dpdk.org (Postfix) with ESMTP id 8BC264CE4 for ; Mon, 5 Nov 2018 20:06:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pRqpWLmfErwn4LHr9FHcHehlCfOxLnQC9ZfeKmU7Nx4=; b=TAof/HFnixQ+IYolTEI66nqSH8YlA+Ocy3OXnuclW1IZkaj6Aa3jagfvDfPA2vfC66oT/Su58f/oYR2ZElWRkRwJ4x9qT9KYtZJc8WypYg3Es7AQrTmla5ZAFsnwtY8/cucCS8x12/J0QHCesdP37DtXWfVIYwJvPPHXwOnycwiyyQe0GCDb8DGzFiFM/njWUPFD/tl/XC7MzLxWRpM5HlzBkH8lVbNueC4SZO8JkNyqVmKJzkx0It6JtmN1heYtu3e7qTDUxzWEfEO/TpAgRihEgcHVzmCmPXdbBJ0y3z8BZNLVDkNusD3h87gF7iJILnHx7XTHU4lr8lAkhYzeeQ== Received: from CO1NAM05FT056.eop-nam05.prod.protection.outlook.com (10.152.96.54) by CO1NAM05HT236.eop-nam05.prod.protection.outlook.com (10.152.97.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.3; Mon, 5 Nov 2018 19:06:10 +0000 Received: from MWHPR22MB0941.namprd22.prod.outlook.com (10.152.96.54) by CO1NAM05FT056.mail.protection.outlook.com (10.152.96.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.3 via Frontend Transport; Mon, 5 Nov 2018 19:06:10 +0000 Received: from MWHPR22MB0941.namprd22.prod.outlook.com ([fe80::51b9:5f37:c01e:87d3]) by MWHPR22MB0941.namprd22.prod.outlook.com ([fe80::51b9:5f37:c01e:87d3%2]) with mapi id 15.20.1294.032; Mon, 5 Nov 2018 19:06:10 +0000 From: Chintan Inbay To: Bruce Richardson CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] Fwd: Disable receiving new flows on a core Thread-Index: AQHUckonnS1xenSb2UalO1bTt6lPyKVAUt6UgAElIYCAABZoFw== Date: Mon, 5 Nov 2018 19:06:10 +0000 Message-ID: References: , <20181105173757.GA25968@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <20181105173757.GA25968@bricha3-MOBL.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:3BD29FF7677B908481B2F015540361A3F565555F40103900171E58BF9C98D199; UpperCasedChecksum:790B6BAF1523A9DB2CE332F1350B8C7A25325A32C9F97EF7D96561D78A479D4F; SizeAsReceived:7265; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [wTBrMCsViwtxe3dKWy6AbFPEtcHjCOaI] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM05HT236; 6:mloo5cOjZ9nsOw2zuGHH5ttr2a/nqAnFNxnm/qk170leKmzxWNqrDfNVTNjfIBg97TwnfAVLxex2z2MhINCStYQ6NA5rmDeLjNPTy4NlPAU/kkTn94X81zFgG01o4u2BNqDv0FNK7IOv8hYvuBFgF9Xg1x8pMJv8+n4/I3TBvW3du9DOS6NM0vHLHRncbK4NK0xTC+ttWddVxgZgcFNefxa2Rmwbl2MBoc6/FzH+h418/FjI+8ZgZ090tdBDxFn47IVxftuwsL4G0lPCRup7vUiGh2JI536nEeG7qAI6tIu8CbVvjLoVfe4yGj1kaUHdn36wI1D2Hkpu10PlVkKQQh23RMtC13vrv3V85XtupEJbwFSfRjDHqD9XAsNZoEPISG6KnZuH1cj9RQVtc+bdrgFtwjPQmScP4PIoN++D+I/PaXz6cEWkWiF2RYyNymzTk52QTvgj6Z5y29+0rH4aZQ==; 5:hpqK3Od9Y3ZRdplf7UTRAXNB7EsbfeQ6BcApRSbPsD2kgFXdRP2PUZPCcV3MgQFEy8Q+Nb8z/8dMfS38kdICO3pIZd+7D+ip3QSjM6zYLm3Y5lpP33lcRwMj1IRLQdfwzM0vOsHbxbbMLUZS89vcuTY4RGuKLrEb/OmIzHyoGnQ=; 7:T5H6qkRpAaG9NsDeceHseILM6KfdmkjBDCQAx7Aj8JQR95JulHEAeSbMP1+J0AdlB4kjfjBFuWRYVBl0GlHuQ4LWKByQ1EgrDsveD5lUeMskAQb7WYFSCle0B+ZsnOuyyWMeNksKYW8jC0E5ohvcFg== x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:CO1NAM05HT236; x-ms-traffictypediagnostic: CO1NAM05HT236: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:CO1NAM05HT236; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM05HT236; x-microsoft-antispam-message-info: a7qV/n2XeUIK0x7l4GqmBVjBGhgdiI/XVgaeuY3oqQ9VcRsAnL9KF/smcEfQPu/Y MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 9a4e3081-9524-43cf-bfc3-dcaef82d5da1 X-MS-Exchange-CrossTenant-Network-Message-Id: 7baa31c8-fc0a-413d-158a-08d64351bf7b X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 9a4e3081-9524-43cf-bfc3-dcaef82d5da1 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2018 19:06:10.2649 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM05HT236 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] Fwd: Disable receiving new flows on a core 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: Mon, 05 Nov 2018 19:06:12 -0000 Thank you for your response. My guess was that to implement this feature in= hardware isn't straightforward and would require support for: - allocating additional memory and keeping track of flow hashes per core - parsing TCP packets for SYN flag - If flow hash matches for a core, send it to a core only if it is non-SYN - Send the SYN packet with a hash that matches the disabled core to a new = core. Which probably needs a lot of work. It would be a great feature for roadmap= if Intel decides to provide it. However I don't know how difficult it woul= d be and if dpdk framework can eventually support it. I foresee it as very useful feature for micro-upgrades or per-core software= upgrades. When upgrading software on a core-by-core basis without losing c= onnection state. Enabling this feature would let a core drain the flows, th= en perform a restart with new software. -Chintan ________________________________ From: Bruce Richardson Sent: Monday, November 5, 2018 9:37 AM To: Chintan Inbay Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Fwd: Disable receiving new flows on a core On Mon, Nov 05, 2018 at 12:08:48AM +0000, Chintan Inbay wrote: > > > > Begin forwarded message: > > From: chintaninbay@outlook.com > Date: November 1, 2018 at 6:19:49 PM PDT > To: users@dpdk.org > Subject: Disable receiving new flows on a core > > Hi, > > We use RSS for distributing flows across cores. Sometimes, in special cas= es we want to disable receiving new flows to a core. Only new flows. So say= if RETA is programmed to receive on cores (0,1,2,3), then the new set woul= d be (0,1,2). Existing flows going to (3) should be retained and forwarded= . Only new flows should not be sent to (3). > > Eventually when core (3) is ready again, we need to re program RETA so th= at all four cores can take flows. So new set of cores would be (0,1,2,3) > > Is this possible? Not really, no. RSS does not track flows individually, only the hashes of the flow's key fields. Therefore there is no way to separate old and new flows, all you can do is move all flows that hash to value X to a new core. Some of those may be old flows and some of them new. Note too that the size of the RETA table limits the number of bits of that hash that are checked. It's generally less than 10 bits. /Bruce > > Also if the process on core 3 goes down or crashes, is there a way to not= ify RSS hardware or you=92d have to reprogram RETA in a signal handler? > > Thanks, > Chintan