From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730071.outbound.protection.outlook.com [40.107.73.71]) by dpdk.org (Postfix) with ESMTP id CF7311E4FA for ; Sun, 10 Jun 2018 14:32:07 +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:X-MS-Exchange-SenderADCheck; bh=VzycBzawb+I6I+XLIFQdcjpwXT1E8BZ4idW203aOaC8=; b=hJDNrqj8dN13+nBKuPBPX7ec0V3wDk9YesPzl9o2A1exBMJTMOVwU/Rq7zI1bs54HoQraQ8kvZgXYlh6dnXrEL1Wmzho6L/+EqhqIDuMX8C5gfN7MjukhnQEnNLhgr8F+Q3IYwnf0eQIDeKHKnVhU72BOBUYbM8fNEFb5gM6+Og= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (118.143.155.128) by SN2PR07MB2526.namprd07.prod.outlook.com (2603:10b6:804:6::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.16; Sun, 10 Jun 2018 12:05:54 +0000 Date: Sun, 10 Jun 2018 17:35:42 +0530 From: Jerin Jacob To: "Rao, Nikhil" Cc: hemant.agrawal@nxp.com, dev@dpdk.org, narender.vangati@intel.com, abhinandan.gujjar@intel.com, gage.eads@intel.com Message-ID: <20180610120541.GA1933@jerin> References: <1527260924-86922-1-git-send-email-nikhil.rao@intel.com> <20180530072633.GA2015@jerin> <72136c5d-64ba-247c-97a8-728054935e7c@intel.com> <20180604051058.GA1913@jerin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) X-Originating-IP: [118.143.155.128] X-ClientProxiedBy: HK0PR03CA0024.apcprd03.prod.outlook.com (2603:1096:203:2e::36) To SN2PR07MB2526.namprd07.prod.outlook.com (2603:10b6:804:6::26) X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:SN2PR07MB2526; X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2526; 3:uBXs/MbT5zUXGj+NnLfspZmMloGRcARGzcuujXzUUf7V1VHt/XTl7XMAmuba7ku/3LHgiBiyaoXNDS1xYv0B/tzma0qDWGBC5Wy2IslV+TWaIV6985QmCHZHXQStPCVFqlK0iYs5l5r5G0cVHAhqPqUXwL9kMPoAUGjcZ3ElLuBxdVDuQZjoOER91yy51XEvGQTVguqHJzbgn0lTPDZ/ahYCTbuKSSJo0OP4qguGmbMoX8RUOQyDXeXvyu+rCxXy; 25:F5Cy9KoC7/ucXn2EwrbxpCYGECNhAlIAb1C1dhz9LklKVv77hIiAL60O73Qo/qSpEqQTyzqZKWPtYIKbQsW53pqzSjPXd/YdZiqnN2FUkF2DObCqKQXUbn/ITXKdJ7zzEHqnuKQeX7KulXMi/Xw5JIQCmFtLVrnsohm53UrsPZ1+ve9bk+qIU18w0FcpLi+bh/534wTMEVZgbFfovZ1W1H41PH2M+V8k+CALbJ1hqYnMaAxw1UTP5YbLGamLV4kUG7uPUOu6qyCfpLmyXHZ+E8fFKIXtzPudVtdePg3zVTRJ6jo4WfZvkYkDtLn5qVDoyttjenv61U+GPuIjZfZRKQ==; 31:H0gws/ksICSF5Pz0EHdselPmjTJYMxFyQ9LMTW7K9r3F1lMH4kX5Ol3/va4rueRUljxYqa45kIXRIg4pvgj8hvIt6pTzapG1LggQocVFDHv+RLCl2Uztu8VZ9JF3+BeDZzyFhQUTKJDUVDQZu8bd8HKVXkEMBsZ/6Bbl9Edb9Tqhipu4T1cA69Rt61A1l++PKd3zuj+SICVPD1mTflxCqQ2pB//IeDqhMxw8rccn43o= X-MS-TrafficTypeDiagnostic: SN2PR07MB2526: X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2526; 20:1bCVS9zLMylovC0oFbz/T1OlMNtWALdcsBWDYrrQ4jJgH73wpXgFHu1BReGj49PJ4DAp/d2FbGDa/qseaHu+mTVWgW0GkSQLB2M6jqwxmKSg2BaFJ27+QfF6YCZuksOjf/B5lPejin9HPlaXd7Sxzp2RySWQ2BP+Ucutd0TsUfHq+QDC3mFlIG02l41uR4XU7wzF3v56yLEBAU4WZLE8FC7Wr3Q4pdARFu7E2LIyjDQdUXu0R56g006phR9N3+MCqm2MJO/Re92eiam+s0LVb5/iS9tmtOs7xhyUrGdmF0vctyzcpzE8dNxR+O0F8MrA3uxLXdDxewltymlTj7q4lyFu61lEltJF0+Rm7tqZUi7DdtcMlVvn2omwwPy7bYjlPvBlIUQRyBiF65lKKQZApzD3qs3OqUxpgip8KB7mTOUVkf04ddOwG8TAJZG8FZl8ylQf0pYw6wI1MaW0WjdYTFZCDVSmbViQStG7sKdk8A6AVcfcZPskYHJMSx6ecz0FEsG8wnteBKekmt1YuSR2RSfcpYBgb0V7MjgRYoyJIPk4f5vGm7Zf7V2DLo8i+iEpXLGAyDLi+lkuNRf9BxXFx+IaQfYcJoVDHLV3KQuhr/o= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(788757137089)(228905959029699); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(10201501046)(93006095)(3002001)(149027)(150027)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:SN2PR07MB2526; BCL:0; PCL:0; RULEID:; SRVR:SN2PR07MB2526; X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2526; 4:PJEUXwmUmJpe4rU7cD8nOzJvRLDNa1Wqs/bB18bHFoYXVhoMOUpeiCIQtK25B4aGkupD2SHmZlIieTPIVy0lPnB+3oZKIeu75MPz7t3F9QzvHuyDbxWZGvqAxhTK2/ch7SGcf+pBkTAFkT825b3Xk2q6yg/3PqopBX3ZNrskno/db68Dh9JzJhvGR+HB74bT8YJmmhTo8Gm/4OdxOqBaMElsiY0oPuPQjNz3Yte5h905lIbvYffbZF18YXozWM9ifziSQ+PtEJXWi1M8egCA41pYkx/ILeJHhPExaEhrSOBtIh6eirg8aWvOju/W7twYWqFGkjb3LJNyAPIRh3qY5HDO0ewNxLw3p2FaTMzUE2oO1Zsl7/TjWCg9miuHsq7D X-Forefront-PRVS: 0699FCD394 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39850400004)(396003)(39380400002)(366004)(199004)(189003)(13464003)(57704003)(186003)(5660300001)(956004)(6916009)(8676002)(11346002)(446003)(6666003)(476003)(486006)(93886005)(58126008)(16526019)(81156014)(53936002)(42882007)(478600001)(26005)(229853002)(72206003)(6246003)(25786009)(6496006)(68736007)(76176011)(53546011)(386003)(52116002)(33896004)(47776003)(81166006)(4326008)(305945005)(1076002)(23726003)(33716001)(97736004)(50466002)(33656002)(8936002)(105586002)(316002)(106356001)(16586007)(55016002)(44832011)(6116002)(66066001)(3846002)(8656006)(7736002)(2906002)(9686003)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR07MB2526; H:jerin; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR07MB2526; 23:XnnJDmDeApeJJ0X8SihmsRys+rc3Qp4fQ7aEfX/K0?= =?us-ascii?Q?meYjw+thgBHDQcAN90GJEPzQUPa3heC36Jh/k10+6MJEkiXLqRoRaNnhKRT+?= =?us-ascii?Q?oFW+B1XmEWQ8azTpcQY7uwfssqz9T/TTJoaETcX9MIV/hq0AIrvdLz5sb9Zm?= =?us-ascii?Q?loPozbvnVwN0uF7fXe6PuZuQf2Fvq7zQAuHvLmMp/xNw86DiBNiqFuQsNmRI?= =?us-ascii?Q?kpVtjpHqGfd+jQIYGQMOSPx4gIb4SXNWTO++/x5nM4LeUUGLVTorVz0nVjWK?= =?us-ascii?Q?HIORrFngdeOj3JYG09j6yB55a3n/i3GZ5/QyeUsfYlk+a+tqZbuPxi9HTQdx?= =?us-ascii?Q?fVwQzvR4T71M99IygVWJ5UBP0eJT8HB8qsMxhfSvo0xlNQS8co7GBUC5dma1?= =?us-ascii?Q?JeHmbNQgz67/fe/ZwbAKAJD4JoBKzC5ZtlBwrNeEdCjsIqr/mTvE6ARuUYTH?= =?us-ascii?Q?HIoCQvKBeRKrD7TFlh3tME+Wx71qmqdoVwPsOOfkAGL0apAjGTHNVEN7mzsu?= =?us-ascii?Q?/Aj8Eul8qs4RvN6zmHKVjw23iQm2jUt638SCTQ0LA7kTLjMAFVcYiduCbQ4a?= =?us-ascii?Q?ETInD7II1w9bxBxOssa+g++UdfWTXbbE3lu8TIOVHie6uSZCTS8PcLfwlZqC?= =?us-ascii?Q?fuXkc+kprxP1in0s4U7QPFaaKc+vY71o4rKxz15nAurpQpNP0VRiBxdB5cFy?= =?us-ascii?Q?Clf3F7M5b6JawHnsFsfPenQlvAvDeHIoPK0ezl7TbrDTpJS5mLGz9zsKyHCX?= =?us-ascii?Q?YJOlRiKf4IUFW+hiaF9Izdkrk9LOpCnVEpX31IhZNL+5/O7IxKjEK8BpjJsq?= =?us-ascii?Q?IbUybYRScO+UkWF83ytyc2Ug8DuNTEtovHTnXNoEsCWHwvpYwOtKPy1hyH2h?= =?us-ascii?Q?tZkg1eh60UDyFu6NBDbrvGXR9SGgQmccnNAIAhHYS1vprBsTrY4YQgR4BFv8?= =?us-ascii?Q?CXy/v6FxCIqt+ei8Vfwqk2IhQOAz/fig10f6fgngD4WpR/ODN3cAvnWqk4h3?= =?us-ascii?Q?orcAUe4bP/o4kQZ15cLIs3aLxwWD2/IBFhriE3+5DGJuyYXMcFtkJE7GsvTn?= =?us-ascii?Q?zN+MQ+mYKDqTIglhIrywgFHav565tzsGA3MuG8JCwOOJ3rJUk2zTwZeK3DAN?= =?us-ascii?Q?tEl9qu0PTnC19KLv4HCnXNB89vpE1hbq+jkBkHrrjdAs/FCmFVdv3KiWrMk8?= =?us-ascii?Q?GCabcTGxNHOnGHHyhF79RKXCsFT2RNa2uKC9YgL8xTdjp4SJRkR5BIpV1zXh?= =?us-ascii?Q?1WmFQzmOgatqUCCBqQ1ahhLKqxG1TAn+25Vq6u9qXO/pbZEOoeRiMK76Oogb?= =?us-ascii?Q?YB6fBKPl0oLQBEU29kalnDi/wo4m9tuIvAuHXjrjIfWoP6wkxiRuSUXBb/tK?= =?us-ascii?Q?Qa7UqB3bgIsYvfFMlzhYBzke0CB0fMdEdg7sJYDaGWFsJOpSgqKW5XLZSx/L?= =?us-ascii?Q?uiSOjx95w=3D=3D?= X-Microsoft-Antispam-Message-Info: WqAhrLLVNsh03giR07oYBHrBEOCHlEPEhg6qDchV/5b5KxRNnZLlsRGPsuMWYFojhZ1cPkaKWq1IUMoN2NZZgfzxZHIRlknr86MUkUI012UUOx+Q6lE8wRYMEcgxI+mnwF2N6qF/ITMnMLhESpSgijC5Z+qVYbg8fKxyYvKhx0AesndLoOsek3IS005waWHF X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2526; 6:sB1gLhIlC6nhsxikXtbzgAS8noxO0SJglfkUnWLespMiu5w64Nl1PB4+Tw8Ha8Kemct8Z0K2fpd6aSclCFy2zZNL2ysfletnhnx4+IyQjFiuRbnnM/G0gjSv0u/FAmkKt0y3tbiuKF7fxCzr+V3f44QxtnHdpgIgtxDyv1kL10r8LLfpoJ0mRBCQx/l4IXtuC77+OylXp1Mxazu9iOlQRRbxcJCC+kzNKih10+/jY4YgmRDGJB6Lrys0dcnzkCQcs0N7Y18GRMAn8NX7Y1JAUzsbCJsTuo9MJdaooF9h/aSCXQVjwuT3QZ5vM2qB3m3ok8Gqbl7bbOwNkEkT/WevUiwmLPDpxNAEzHP1wUr7Y3X42Ibc7HF5YYHBrrTHHZoZvkm+QLFcc4Kn8f10yAv/SWuezx0SMXVkHJJGX+8iL5352LvBlJpj1zsaDHbijgBB4Wij8/4WmH03u0ac8kmabA==; 5:AJEtEqM86oyIuklAyRkEhu4eEmEdseXSM5oXKKCcGRhhhCRv87y9C48IycAaf1Yb66O7TSSipN2GjCGo+kvn9JkE0603iGwYpprFexlpmv2u24t8a6JMq7fYFBh6zig0GW7MlJmbEJ/9iLFc+1QkVLtp0s/71iaR/epw0axz6UI=; 24:qfniAoq5sbQnu+gS8JG2pBlPHnyPnlKh+Q9mmbCLscOEuzy0bkV4YSjZ9IDXMUBH4HpN7rz7vb74k0YzhAdhJQ4hPpVk+ft2KSL9CACQ6yY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR07MB2526; 7:bR062Ot5Tx8Rj7BjndBGHP5TXmM3fdRQuMFAYDWmHYHMz7evSDX0j4+SwdnbtP0oJSnLbgiuW69CXG7gk+da8vqwQiTStoqhivPGYrFZBfRRdG5fscWuc6Bs9HymsOpSRBfSnJI9bPxqpAeaE9fpdcEYG1xqQ1nyjkrkuizsm3fsb5gLK4zXKcPrfyrDdDtAAqpU/WtK3m/A2mClJJQB4GO1u1gqiWxSe7u2dj9XJPaKFRlnkIwE3O30oNxfVspa X-MS-Office365-Filtering-Correlation-Id: c63922c8-f783-4b35-7c6f-08d5ceca8556 X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2018 12:05:54.2140 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c63922c8-f783-4b35-7c6f-08d5ceca8556 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR07MB2526 Subject: Re: [dpdk-dev] [RFC] eventdev: event tx adapter APIs 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: Sun, 10 Jun 2018 12:32:08 -0000 -----Original Message----- > Date: Tue, 5 Jun 2018 14:54:58 +0530 > From: "Rao, Nikhil" > To: Jerin Jacob > CC: hemant.agrawal@nxp.com, dev@dpdk.org, narender.vangati@intel.com, > abhinandan.gujjar@intel.com, gage.eads@intel.com, nikhil.rao@intel.com > Subject: Re: [RFC] eventdev: event tx adapter APIs > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.8.0 > > On 6/4/2018 10:41 AM, Jerin Jacob wrote: > > -----Original Message----- > > > Date: Fri, 1 Jun 2018 23:47:00 +0530 > > > From: "Rao, Nikhil" > > > To: Jerin Jacob > > > CC: hemant.agrawal@nxp.com, dev@dpdk.org, narender.vangati@intel.com, > > > abhinandan.gujjar@intel.com, gage.eads@intel.com, nikhil.rao@intel.com > > > Subject: Re: [RFC] eventdev: event tx adapter APIs > > > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > > > Thunderbird/52.8.0 > > > > > > > > > Hi Jerin, > > > > > > > The workers invoke rte_event_enqueue_burst() to their local port not to the > > > extra port as you described. The queue ID specified when > > > enqueuing is linked to the the adapter's port, the adapter reads these > > > events and transmits mbufs on the > > > ethernet port and queue specified in these mbufs. The diagram below > > > illustrates what I just described. > > > > > > +------+ > > > | | +----+ > > > |Worker+-->+port+--+ > > > | | +----+ | +----+ > > > +------+ | +-->+eth0| > > > | +---------+ +-------+ | +----+ > > > +--+ | +----+ | +---+ +----+ > > > | Queue +-->+port+-->+Adapter|------>+eth1| > > > +--+ | +----+ | +---+ +----+ > > > +------+ | +---------+ +-------+ | +----+ > > > | | +----+ | +-->+eth2| > > > |Worker+-->+port+--+ +----+ > > > | | +----+ > > > +------+ > > > > > > Makes sense. One suggestion here, Since we have ALL type queue and > > normal queues, Can we move the queue change or sched_type change code > > from the application and move that down to function pointer abstraction(any > > way adapter knows which queues to enqueue for), that way we can have same > > final stage code for ALL type queues and Normal queues. > > > Yes, I see the queue/sched type change approach followed in > pipeline_worker_tx.c, a queue id can be provided in > rte_event_eth_tx_adapter_conf > > +struct rte_event_eth_tx_adapter_conf { > + uint8_t event_port_id; > + /**< Event port identifier, the adapter dequeues mbuf events from this > + * port. > + */ > + uint16_t tx_metadata_off; > + /**< Offset of struct rte_event_eth_tx_adapter_meta in the private > + * area of the mbuf > + */ > + uint32_t max_nb_tx; > + /**< The adapter can return early if it has processed at least > + * max_nb_tx mbufs. This isn't treated as a requirement; batching may > + * cause the adapter to process more than max_nb_tx mbufs. > + */ > +}; > > > > > > The worker core will receive events pointing to mbufs that need to be > > > transmitted to different > > > ports/queues, as described above. The port and the queue will be populated > > > in the mbuf and the > > > API can be as below > > > > > > uint16_t rte_event_eth_tx_adapter_enqueue(uint8_t instance_id, uint8_t event_port_id, const struct rte_event ev[], uint16_t nb_events); > > > > > > Let me know if that works for you. > > > > Yes. That API works for me. I think, we can leverage "struct > > rte_eventdev" area for adding new function pointer. Just like > > enqueue_new_burst, enqueue_forward_burst variants, we can add one more > > there, so that we can reuse that hot cacheline for all fastpath function pointer case. > > That would translate to adding "uint8_t dev_id" on the above API. > The dev_id can be derived from the instance_id, does that work ? Do we need to that in fastpath?, IMO, if you can do that in slow path then it is fine. > > I need some clarification on the configuration API/flow. The > eventdev_pipeline sample app checks if DEV_TX_OFFLOAD_MT_LOCKFREE flag is > set on all ethernet devices and if so, uses the pipeline_worker_tx path as > opposed to the "consumer" function, Yes. > if we were to use the adapter to replace > some of the sample code then it seems like the > RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT is hardware assist for the > pipeline worker tx mode, the adapter would support 2 modes (consumer and > worker_tx, borrowing terminology from the sample), worker_tx would only be > supported if the eventdev supports > RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT (at least in the first version) I think the flow can be 1) rte_event_eth_tx_adapter_enqueue() function should simply call, struct rte_eventdev *dev = &rte_eventdev[dev_id]; return (*dev->eth_tx_adapter_enqueue)(...); 2) You can expose generic version of "eth_tx_adapter_enqueue" in Tx adapter. If drivers does not set the "eth_tx_adapter_enqueue" function pointer or DEV_TX_OFFLOAD_MT_LOCKFREE flag is NOT set on all ethernet devices _then_ in common code we can assign "eth_tx_adapter_enqueue" function pointer as your generic Tx adapter function pointer. 3) I think, you can focus only on generic "consumer" case as you can not test "worker_tx" case. We are planning to add more optimized raw "worker_tx" case in driver(Point 2 will allow that by having driver specific "eth_tx_adapter_enqueue" function pointer). /Jerin > > Thanks, > Nikhil >