From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0057.outbound.protection.outlook.com [104.47.33.57]) by dpdk.org (Postfix) with ESMTP id 005E42F42 for ; Sat, 6 May 2017 16:26:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vEkH1tH8RZLVvHOBicJDmS/okwcb/4JzzU/GyEkbhwo=; b=JkW+eW+sLUbRiozSd0Z6DkvojiG5jOnBomH+o76poWNfm+FFH0+SP5x/UJ1fTuGKr9zn4ndLwTwLY1aua+RbdnnsiZ2o746Ews8lNvLcHuu5TW0Ttn5ohbzc1e+EJXQxt4c1xaPCtSIuypGXGAiSQVXFZDeNlZWxlr9pNGuUDmQ= Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=caviumnetworks.com; Received: from jerin (106.201.118.5) by BY1PR0701MB1722.namprd07.prod.outlook.com (10.162.111.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Sat, 6 May 2017 14:26:35 +0000 Date: Sat, 6 May 2017 19:56:15 +0530 From: Jerin Jacob To: "Van Haaren, Harry" Cc: "dev@dpdk.org" , "Richardson, Bruce" , "hemant.agrawal@nxp.com" , "nipun.gupta@nxp.com" , "Vangati, Narender" , "Eads, Gage" Message-ID: <20170506142613.GA15598@jerin> References: <1493810961-139469-1-git-send-email-harry.van.haaren@intel.com> <1493810961-139469-2-git-send-email-harry.van.haaren@intel.com> <20170504063543.GA2794@jerin> <20170504120121.GA29312@jerin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) X-Originating-IP: [106.201.118.5] X-ClientProxiedBy: BM1PR01CA0053.INDPRD01.PROD.OUTLOOK.COM (10.163.199.25) To BY1PR0701MB1722.namprd07.prod.outlook.com (10.162.111.141) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 29605451-0d82-4830-0563-08d4948be872 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:BY1PR0701MB1722; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 3:jDdlHlsR7xFRm7L5tIK4oKDKsEpOBjfjB/a44qtiRY01bJYR7zmvK3YFuTfmirQbRoLpWBzgeyG21XsZgTC5afwD7LCP1zhyemG3jH3bGZsvwr9jJOhNjYjWY83Fb+5WLPHYbgGfrwmT91P1F6rhfML/tw3iq822Rsx0KDo83ymFep10PiwQv59tDZ31qDm+rlst1sQofE/TQAzrCxLPLD0OYVp97Gw7UMSuKrFLZ8aYBIVWW33RgWX1C1vmiSDQ6BamH7GWKZZ6W7RO4hWlgMk1v30gFHL/Oc5WeuM4Witn/UhYKbRNrg2eHzJnJj2tzUYoZ5Xjyafaq46Z9I5WEg==; 25:SDouEgGKEsPVtg3aZ9i5nLwqifXjIQcddDPy/uynmJQKwdcRMyegOJws0uZwS0ePm88SdJBpJkrKliNLn5IXLQgZ/Ws+YgZia1B93abQFsGDc5LNkuLaYnYOtEDdjpZh0K/uLDliMF7k1zS4mxq6yJqd2lvOR9j85Nv1xW2WLe+b2YUNCSClxMn1YyG87j92bNGXgJplDIx+PZ1SnS2oHBw+X11nDfJ3P9H7vH1my4DKTGswi2d/gR6m3mFDxmMbPdkjpjeD1mnYmXSCjiNVmeksGqMWEcFql/IV9MkU8PxLus2rKd+gjTMFzPHYGsJb8ty+X6kwpQ0xXP5O5rD36zuX+8pW7zKuQzz5tBLh9M15EQ3gnFAwhZLOaIEvHPX6qOKdcuCUAe4dJO4f+yBNwL6OougSbBkAVcQkOnB8qw4O7A8nRYGzXiOjVHuW/UtLKl29Dr3rkFdRO1/tuvh4Gg== X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 31:pepIt+05AK/UaAHbb/fYoK8/SMqvoZlHwkmKz+Y/E0axVL70mpW0wHPb+Ql82MkpQfmT41QTowH6sFLDOeJOg6UDwt8NRKQPZToawEAUguol136+t9cDg2TAwh2luKjZKJCXWC3DSHobmsYgtTJK9Bme0r9XiqvXrmQHZHd1OLNvdMvFqaGwQOTicT9Ym3m5YZ8zXvd4zUjhnxo4VLaKR6RrlfExe8IwLSgEfozsVWHN79JKLNw+EEzAzoaYeoRInbUA5N211sk1Mb1S6r82Iw==; 20:Zxm5B3uqwO9ELv7aJX2FQMykTn6jbvMtyitYfHSOeSKFyYDq2gS94dv211bEGF5EdC0WOP8xWHFJ13X5z9BHnaXDCDNd0033IC6avEY3YXyi78GS6hutBycgagktld7IbThWvBiAz1IR7Espl6YA+oSWKTkHi2WyCftdYORI+Hk39bXP+o9+z8wAdqPEhR24K3GF8auonso4ijNBYtROcMJ1MV91tWSLf2m0J1Y1SQjDsP+6FG9C1tLbJSkQhCGXwqLvEGPEC1qBgCr5Vak6d1lduNXWPMTNPO5vA1bklNdBXf4WWvgVb67H6LDkl++sWCiVgjKWv3C0Ep5cF4a419dyMI4AdBmWkIDtr0dEyse5/kGhr9V008pWmiZxJ8EmNK6cjSvES8jPrZx/HKv3nPkp9aUE0uDmrr8RdbBSmZLX73mj35jOZeTzrswp54gWbh8f/uWx7xptZE9k0GAMo7glvqlD38Vr4uQhT7a0Y45bWQzYy0ZZZnPSvc0fgZETGtdhMPVhqLSAhNYJIdZ0y9UmGwGAOVre8ycmHqVpfr4pk8jxR6PqZ0S0SAZ4wiT/+7LsE/qjJwmPbiGVYzzoBdvFifLPv0m5vvJEt0DpBx4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:BY1PR0701MB1722; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0701MB1722; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 4:2QpplBc6aY/gBtrD9mAPi1loaCAppKLA/ZD/EXBp624bQelSSp6MSBlu3uv9eGH0oMc+Bzn0iQnRn6hZlx+O1QFWp8nkpFkxm4iCp5jerandDEBH60QPL+93hLDi5oY4XGy2XpYVRoqRa8aaRkXosGCe6cLatmiUGQUcg6SDHSk4xwPS7ifcQiBKN8bVC4TLHhctA/U6zfC+gjSaQ05dtH5PRS0HEllj1w3dWNV3utL79UBWmC6syeTSpe1aj+2Y1oes6idaJZbt9Om52KHHGD2nuBGF1BrNdKtbvpwFgZZaUKm9moFgOhlZQPMJAqFiwYejg0+zyGPrJn4AR883HpbfdTH6lX/G9L7w1ySHMjtpItWMm6jASASJC2brWsbkz+dK+mA6YLmQnF1p5Xa+haxAHYtXn6Mtf2xpzYXfPKTh/iXGWK0HQxyCy+M9zzPdaRwUlPA90aoGZaIdBQnNMHLP+HQhw2Yy+PhiE2pcWdbYi1bkj3vUc/Rv5f3Dwdv1Qj3tiYpRgKQHZecHys0jjHVOpDJaF27ubXxomJJI2N/QIxnwRsZ+itbQUYshsWkTlTg3xlLsSZUwHVoiraTO8wU5O1ZXDkChNFR6CYrJoA2A022Y1A5HDbKK0t/b5JWJOfjCoNW3R5szXSZZ/n2pjCuygSANjmQk4qcHVUhfBHIDJffy/iaOa8o6Rax6RkGeOechvMPRVFTsQX8gwO1RJBHPaZO9NofUhdxXDIVF/05aLubSlcarz4gcfOctAAnQfU7sf2oe9xN6HRdewRXva0patnnl6cAoo2+bBlN/jeeEK5uhtnTT0N/d8cIlPhtgvUYMlmw5kEAdJsv73YIwBQ== X-Forefront-PRVS: 029976C540 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(39840400002)(39450400003)(39400400002)(39410400002)(39850400002)(33656002)(6916009)(4001350100001)(33716001)(478600001)(42882006)(93886004)(2950100002)(2906002)(6666003)(23726003)(38730400002)(6116002)(3846002)(53936002)(1076002)(110136004)(50466002)(83506001)(6246003)(8676002)(55016002)(42186005)(81166006)(50986999)(25786009)(54356999)(76176999)(47776003)(189998001)(66066001)(4326008)(7736002)(5660300001)(229853002)(305945005)(8656002)(5009440100003)(9686003)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0701MB1722; H:jerin; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0701MB1722; 23:fIatoz4YMnacIMOiS3zYWojX4sg5lgyxVGwO1Ne?= =?us-ascii?Q?cHc4ZyuCePo+khuf0YRhhq7tmKc31YEwMecy17McuyKsvGSag8LawQMEpM35?= =?us-ascii?Q?BeqQ1B7FPqWVBtYl3C8FTSvR9tCJJT6b3VD4fW2Z0dLV33AsQ55uiZEf8W07?= =?us-ascii?Q?t/t+juBCMG5YNkiQLvpJd2lPN3LV0bu41pzY3bN67FHYiJkQmNxkcXAGCpgu?= =?us-ascii?Q?cM/fUV88RRlMRfheUz2B1jQnBeBt3Q5ktFm4Nf6ZV0n/KNKrcfpAII9VGIQn?= =?us-ascii?Q?//tkgieEzyGRwdvVs7VoyjPoPjIPFyZs8f5DcwII+I58uJolmyZI99apmdn5?= =?us-ascii?Q?gvWiZPaMk8wZL5PTCanBw9fOI7T4Ao4M6m6+tleBg19yigoZX4Rkq/UMnUhL?= =?us-ascii?Q?yegfoZhV50gKhDS3JcFEYj8orWr0pSuLvNwpS/ZcLL6Vcfy4/hjNbhpWrTvX?= =?us-ascii?Q?Mvdh3NH+t5XG7Di0ZG10Ha3yl4UrCwXSXvnlR0E366Ql40eAczIBZlSy0vSk?= =?us-ascii?Q?NWmE/f14vRM4kYgnBIwoRfwpMaRuOeyJQ/VJetEtOX3EbyYAjV0jrDM7v7qT?= =?us-ascii?Q?h0VXrtDaiEodRNnwcY69yE2AYUzD+cqc2ELGF6QZ1nPb9CX2QFC8/83kbxo4?= =?us-ascii?Q?17mM21pz6L7fCGv1AMEEqiAOUIJ7tSJsD/0mJnkdq9w730qA27Yg2LzQtODr?= =?us-ascii?Q?1v0t2CFM33naPQQiIP7E1mL2akOfNbpZXyfh/zTbUCOc3E4yJhuV/vtojRkX?= =?us-ascii?Q?WGhA0idl8jP6VzbCnexh8Jz+xIlhU1OUWpyCssTDp3Jl8gHsIyq/SyXeSxFi?= =?us-ascii?Q?f6XT27l1CKbMy4Gwxsji7tILUoRerDPoDPWrCWtiv2kF/ru3BkdxR+EF+P2F?= =?us-ascii?Q?1Wd8pzKMJAv0kB29/6JcQ6nm9o9gVMQeydY5l4yIT6QNrhz+D15lTblapKUj?= =?us-ascii?Q?+q62vhq6sCsq6uvJ0JVcHVUrTT/578+ZY4QLpC1JjH/X7NJsGey+tDPg0fMb?= =?us-ascii?Q?of8OlFh/q6XVhc56ayJI1FolJdOCORkd9ol+IdmvQlZWdeZugncSOmtMQLUG?= =?us-ascii?Q?P2rAwPXUTuHJqdVxFEJX+8XmCxoQUplf5v78Fr2VxUnmTDvek/Y8Ns4cioB1?= =?us-ascii?Q?Pcf6IRQ5wwonA+rwVtx+oE23HNkcOv+uVFLOgmmqiha7uQB/g1JE3vqe2T+R?= =?us-ascii?Q?fFwmHkV3EAsiVO94=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 6:1Y9TrRvi+5n/RepRymHPZPt5OnGNjx/v0JB8w8kLLbonpIfEVWVUZwGpef+TIv/VvRxhbyahFuUVvbL7iZYg4iLohZJHj7jtNAIeSavD2ZUdKIGnCA7heNFNEDEQXNwKg1tQq1s7irDjWS+TOHJN1c5E1LsS//kXAWTRVKJ+QZezQhfkWZtmbmDi/MXspzzEb+SUDWW8cJGQ5dRd3rCHEjX/dN8xQmXuyysbi+4+nqH+F6fhUHZRnaWLbNQTCMAsgH7gfaVZ/8QxPx7yWWMgE6Za30q80Atg+9Gt8kHm/f4rTfr+rMKe3xjL+ALi4uS0Bu0N1kOPVCQXpZKNWlgdEc2W+nfi+dTPp2NhYKalPdEf765LM8rGbSM0W7gaR6KDz7LXSK9pYDbWxUwnvX9yp3xwt+IPLTrcraGQGRtEt/QPdl4UbfBvVexq9IBdL/U/DWccREfGUXjWTzFxjfj43A/ONq5oEeUT7ANqPs6P1LxYClQRq4Ww5IqwAIQ3KbPkb+CQKYxLVchgKXYCttCgYg==; 5:B0Q8dqeDylAEJtVPTVMYaSwK7iz8ZIbiRS0zXt1TrmS+y2ym32oJfG1O5DUk63ANSruQEATiocNBajhKNXDcsofcZsztdrwljxUqPCzAkdGr/7jjHwv1JpjhO2Y6Ya7FqqbXs/uJO6/3yezJ46bFnw==; 24:YnJOhCVQgdrCjTD2+DBBmJgOlxsLtquNEK7uTVjDHfbXx/Ye9CPq00BAQn1YMj8UABxgl2akGknEXpILWJtAjAuw92jI2AhETURTQ89LOtc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY1PR0701MB1722; 7:7RSSEz4cEmz3Xq3VPtMp0ioYxtziJahAJiIpcWTm7LJZhSbLxHfBUe696iz7u2eJFiPyOn8MmYNeyckLGORWI41benJCc87rfic2k9/vU6ceKLsAzSWIMBtkMULzf3xKelds1iGKgEZH96G692vHOTZ1m0wgzXwQgJwAkzmwdfIsZlQZlsH4yqLlHuJsWx2VbxsyIM7QsigA6+pCXNRpNVeusFnENTKfYzCyKxyqi8cMVmxIO3agCNTHeKwknMedP4APMh9HmejjVouANzPs2AnmySTzl7fLZK74PEJw6PMkXuHXCLDvR4QZ5xCVZTn/odURopQrJZcpEBSI2Q04Zw== X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 May 2017 14:26:35.7980 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0701MB1722 Subject: Re: [dpdk-dev] [RFC] service core concept header implementation 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: Sat, 06 May 2017 14:26:43 -0000 -----Original Message----- > Date: Fri, 5 May 2017 15:48:02 +0000 > From: "Van Haaren, Harry" > To: Jerin Jacob > CC: "dev@dpdk.org" , "Richardson, Bruce" > , "hemant.agrawal@nxp.com" > , "nipun.gupta@nxp.com" , > "Vangati, Narender" , "Eads, Gage" > > Subject: RE: [RFC] service core concept header implementation > > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > > Hi Harry, > > > > > > Overall it looks good. Some initial comments > > Off to a good start! Replies inline, in general I think we're on the same page. This RFC was pretty "fresh", mostly to check if the community agrees with the general concept of service-cores. The implementation details (although going well) will have some churn I expect :) > > I'd like opinions from others in the community - I'll leave this thread "open" for a while to get more feedback, and rework a v2 RFC then. > > Thanks for your review - Harry > > > > > > > > Regarding step 4 and 5, It looks like, > > > a) The lcore_id information is duplicate in step 4 and 5. > > > Not really duplicated - keep in mind we do not want to have a 1:1 mapping, the goal of this is to allow e.g. 3 cores -> 5 services type mappings, where the work is shared between the cores. Hence, setting coremasks and setting lcores to use are very related, but not quite the same. > > > > > b) On rte_eal_service_set_coremask() failure, you may the need > > > inverse of rte_eal_service_use_lcore()(setting back to worker/normal > > > lcore) > > We can pass the "type" of lcore as an argument to a function: > > #define RTE_EAL_SERVICE_TYPE_APPLICATION 0 > #define RTE_EAL_SERVICE_TYPE_SERVICE 1 > > rte_eal_service_set_lcore_type(uint32_t type); > > Allows adding more core types (if anybody can think of any) and avoids function-count bloat :) > > > > > But I understand the need for step 5. > > > > > > How about changing the (4) and (5) as > > > > > > step 4) rte_eal_service_set_coremask > > > step 5) rte_eal_service_apply(void)(or similar name) for error check and > > > ensure at least on core is going to be running the service. > > So the sequence would be: > > for( i < app_n_service_cores ) > rte_eal_service_set_lcore_type( SERVICE ); > > for( i < services_count ) > rte_eal_serivce_set_coremask( app_decided_coremask_here ); I thought, The application may not need to set the explicit rte_eal_service_set_lcore_type, it can be internally set by rte_eal_service_set_coremask i.e for( i < services_count ) rte_eal_service_set_coremask( app_decided_coremask_here ); int ret = rte_eal_service_apply(); rte_eal_service_set_coremask(app_decided_coremask_here) { proposed_implementation; for_each_bit_set(app_decided_coremask_here) rte_eal_service_set_lcore_type(SERVICE); } > > int ret = rte_eal_service_apply(); > > if(ret) { > /* application can rte_panic(), or reset CPU cores to default APP state and continue */ > } > > /* application profits from service-cores feature in EAL */ > > > 2) What would be the tear down sequence of the service core especially when > > device stop or close happens? > > Good question. Being able to "turn off" a single service while keeping other services running would be useful I think. That might require some extra tracking at the implementation layer, but perhaps something that's worth doing. Opinions and use-cases welcome here! I think it makes sense to add "turn off" support for each service functions as we are multiplexing the service core. > > >