From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id BBF4CA00C3; Tue, 18 Jan 2022 09:49:09 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CA86842732; Tue, 18 Jan 2022 09:48:43 +0100 (CET) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2080.outbound.protection.outlook.com [40.107.94.80]) by mails.dpdk.org (Postfix) with ESMTP id 2CB774067E for ; Tue, 18 Jan 2022 06:22:23 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ofr478gNLt0lqy5iGVNToi0LujRDzQiCi2VxliSG0Pdbm59uk/kRLynX/yMBObhIY7PI/5F6Vd5msiwM3jmEynlYWNp8d679iesR5i/OVM8f2yUou04zaftBpQT7HvEpjSsG9NW/G7HTZsVaqj/qfNf8ilY2bPsMXC/8hhEprkBE+8J/EniRntj6hO5Qt2QPcNK9K5kXgtHYhl8dwp31b2T4RnF79aBhs+nMYpdUmz6dCXupQjNoUciBfv1nq1tAtI0utUCFP8JZtTAj5ztbgaLIzcBMFu7JVKqffigep0+mUwkHj8B0AcUMwPcv0+JJBnm6yk2J+K/1PtYGm4HJuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=irTFarYJRIKEwcg8L9IqEuuuDJ04EjxMOum7sY1hbBU=; b=my+wTge00bCI6JuQ6EePzvQVd0/kue7rpnopOmGYCqir0UaooVSFI1AdsfXshHJ0q6F7JQgt1qNs++COHzrMmQ4INZ6ipyzVvBe+A7H0xLZTvUNTxgD/pRUJKYnKJ6F6lkduYlLmyL3G0K3ZmgU47cFlztDqLeiB1BJ62zTQXGRHpS5YSPFgZmhIbVifCnRMkyGuSgAkV0sD89St+9aoP+edDFUvWcyNqIgbvIBA7hFXbFbNjDTs//drzypeFnAzUxrI4iT+4G4LpF47Sis6aMMSsWHDsfOvap7K4RJL5d+Kow6wPEK0imB3NYHuMfeSqBZP0iKKadXpT97XhpDmWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vmware.com; dmarc=pass action=none header.from=vmware.com; dkim=pass header.d=vmware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=irTFarYJRIKEwcg8L9IqEuuuDJ04EjxMOum7sY1hbBU=; b=mdlRk/37b1f86pF9sO/VOZr1rNzF7NORrjJcG8fCIMI01P9Z5cX3F4a732xTCjYfhAF9IYMmcsyjswjlAk3k2Ly0z1p1xiSWoc57CbAnPSw0Ptk8kUQApDJ3Xg1bH723Nv/ShUHWwrPDRK3qohcfV2nle3QmjP0gTjjJfGSi05E= Received: from SN6PR05MB4895.namprd05.prod.outlook.com (2603:10b6:805:9c::25) by BYAPR05MB5223.namprd05.prod.outlook.com (2603:10b6:a03:9f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4909.7; Tue, 18 Jan 2022 05:22:19 +0000 Received: from SN6PR05MB4895.namprd05.prod.outlook.com ([fe80::add9:2744:8322:b7f5]) by SN6PR05MB4895.namprd05.prod.outlook.com ([fe80::add9:2744:8322:b7f5%6]) with mapi id 15.20.4909.007; Tue, 18 Jan 2022 05:22:19 +0000 From: Kumara Parameshwaran To: Stephen Hemminger , Kumara Parameshwaran CC: "keith.wiles@intel.com" , "dev@dpdk.org" Subject: Re: [PATCH] net/tap: Bug fix to populate fds in secondary process Thread-Topic: [PATCH] net/tap: Bug fix to populate fds in secondary process Thread-Index: AQHX4nw83Zkm9pLdNEORTB8YW8L28axoGuaAgABta0o= Date: Tue, 18 Jan 2022 05:22:19 +0000 Message-ID: References: <20211126041515.96259-1-kumaraparamesh92@gmail.com> <20220117141655.2a375448@hermes.local> In-Reply-To: <20220117141655.2a375448@hermes.local> Accept-Language: en-GB, en-US Content-Language: en-GB X-Mentions: stephen@networkplumber.org X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 170c4cc6-0152-973e-2554-26b96f7b9f9f authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=vmware.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2eadef09-fcd8-4b8b-872a-08d9da427fae x-ms-traffictypediagnostic: BYAPR05MB5223:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4InbqWu7xubuIUAqHkcZoekeU6kS8ZlnYNLA58CWMUKq9/ULWuVCxnrMXzLXL/4FVbcaKhuBbEgRD8dEmU4y2k1GMrtsnTiNdVBGBACTLgR0sftKrskQF80OCioC25qkyH4wL9F8ZOTnnOmBcofihYPU8eXwRIhTpnWalrq4jGrxC+TALqPWDzmkBiCFIcWAQnGY++LjIWooCx8fNDIS7XShmRoho8szix404HI5iA5cMX4L52rlyxg4k7cn9+2k6co9RRWLP8kB/uTQt25ps2pMOWwLWRFhlu7CXTS2Yrxg497AWk7bfnSfKS7c6thQvZ8wsycP2vhey2Kb35LwarF3LqvCiqRlqRxbeDyIJWsqggOjBed8c1SWQdlamqkzuMnu/OHhMc92/O00Y3IRify+LNT3p9rYwuvAI70uqyZeJIjhU16CmLha+EAdTeC16K7DDPLtJoiRNOj296OtoisGnC9q0yCbr9EmM7EPWjqMTS6YGoZeK2FmFOoEpllQilXWRp5ANrvfI7vRJZepbI88qAPMwpGSs3mFdikQEfeVJ4l2wUiK81uTfwdbWmeZCNU8UOujp5yNmSjf2kgBBMptVO0ljmN+5w3fEi/+i/BmvE/yqhm5TVLFHRbErmskSMOQ5ybXJ0U7tSlC7aVNRVHw9sR3PW9Ta7SW42aHQ1oxgeN49Mbhf2KiQVNbmS9a6oRCTYC1XVxFeeRA54lyPFpnNPNdW47V+WTThI0ldozlWqImIJIby4Vxjb3/PVtN x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR05MB4895.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(83380400001)(66556008)(64756008)(66476007)(316002)(4326008)(66946007)(122000001)(54906003)(55016003)(86362001)(76116006)(110136005)(66446008)(8676002)(8936002)(91956017)(38100700002)(7696005)(19627405001)(6506007)(9686003)(5660300002)(52536014)(53546011)(186003)(26005)(38070700005)(2906002)(55236004)(33656002)(71200400001)(508600001)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?CCeNVnGj4RQiWUIvpjn/fnqAixvIarmZfJWy/HbWVswP7NvGFdI3E/eN5avQ?= =?us-ascii?Q?oPG8R8FFebiazPSlqtMQdA76rE7hJbHB+RGmBmj4qSmov9zSIXGgUs/z5NVH?= =?us-ascii?Q?g+NqdNbKYr4ppDHQ0pAGhMQvaoPkpacbM1WXV6C12YA4VmqdwhLh5CfQFaej?= =?us-ascii?Q?Mt6HEhhAhpx2TzYMEjCB/FF73br3dMZQRRevA+A1PSixZE59l50vlzCqkeJ9?= =?us-ascii?Q?Jm3sy/en29/uN90yd4oYIbYANLDOo/GuuKjAzsI6ElyKv2ZyfC3SB/R5UBWB?= =?us-ascii?Q?k9j4G9Zuj4rURrqrVwopcB4P7BeHdHwZ+tSd0q1hWSKLzXHi8W76KrTMrzon?= =?us-ascii?Q?dY+NHHc/E9TWlTgp6q83h2BIYVK1n+c4nhzqFmk+fuOm8tyHWmlKkIX0hAzm?= =?us-ascii?Q?yDy8I2JsBwb16wTyHCvIY0hQkUuyhyIKQm56p9x/KyPXyezOnvMheJTzw1Hc?= =?us-ascii?Q?KF3amCAT9kLYipQw3tLJ+8YO+TlXAwWElCmL6prqM54XQ7WuKNVi+SZwFDUj?= =?us-ascii?Q?aL+WA4sOX7iow8cuS6S4NWufkdbkSMppLPffSmq1LKQ9q8F4CbZ1G4utMrRR?= =?us-ascii?Q?4j6754od4V5wpAbHTpya1JIHok5mQXZNHmP7fopRJIDHhnZbgrQue35Ly4JJ?= =?us-ascii?Q?bdtP2TE+nISkWcI0qRJrbwTBGFkALS6EwdISIsz2zzNdpfewPV5S7sItexvZ?= =?us-ascii?Q?oX1x6JJuAssQ+q+vDpxTmleBVksEmbioyQZB6B56YGhLlxSa4IgN6sLZvqLt?= =?us-ascii?Q?UZix62bql96mZdCdZl4Kc+G/Is3ciz0F6ebyyrA++DJlsdOpylv0uWUSG50F?= =?us-ascii?Q?LaeFpB6wuS/KPyAzwEbZPL0CPDlKnj/5QCwcODTnHhT1OKmB0p1fujDWom8R?= =?us-ascii?Q?2TcihAZ5GcGYlqWu9q+ZjFCV1kgTc0FzUnjqU6IjnNG3zJXqQjPxQAty8rif?= =?us-ascii?Q?c0D14Ym+URGCp67EQpv3S6UReXh5ke23pfOyUU3azHlndk1H2V3U20PxDvPI?= =?us-ascii?Q?w8UgFW3qaRdi4w98E7/nDyodbZul7JNsEJvqmEFb+M2EJNe4Yixbj4JsDj17?= =?us-ascii?Q?T4t15VoQ4w7wIsgNpD8J5pfQAlsKugDLgA/2d7lnVLNMFj6e5Ct0XWfMpyLd?= =?us-ascii?Q?e+XXMESEEO4M4u4MtBbbNpuwCvT0YdHZub7J1zzBwGQAEvsPxJGVyDNJ0Hr+?= =?us-ascii?Q?qZNBUB8gwBRgqygap5q2vrelvQXz2cQTMqi45XeMLr8+A2oP0688WTmY6sgV?= =?us-ascii?Q?P+656zDV17G7JY1vZ7hHNb72myxjigI5FQeI9kAFZfG3+T4jkX/8wbW4Fmv0?= =?us-ascii?Q?nCJfvne9LjdPAWW7mao/ygMO/7i7wPj35mae9pJOnnOP2GOqrUbO8u6CnVZJ?= =?us-ascii?Q?HxRz3EsdVR1pwZ2E1Qjg5spDSlMRaNL3bPHsSt6aWfeNzSdoSaIrwkEC0KoG?= =?us-ascii?Q?ELQIuol4euMPiDd00qkdL46V9WM0wKT7Yw/pl8jvyhZkTAcnkFa4Zc2PEDBH?= =?us-ascii?Q?mxSQwRtwqLqB+DEmxTbWmb2TyLHnYg87E0EsjWp+DOReAisTPlMpHDEB4mEb?= =?us-ascii?Q?RD1ZvzBOq4ZVJk8h3Tdx0lQJfMbpfLLgP2BfmALV0RbaYmaMGpEPdoMxoiL8?= =?us-ascii?Q?Cg=3D=3D?= Content-Type: multipart/alternative; boundary="_000_SN6PR05MB489540C7514CE53DF7A1BB3EB1589SN6PR05MB4895namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR05MB4895.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2eadef09-fcd8-4b8b-872a-08d9da427fae X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2022 05:22:19.3382 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: x3gsmefsv1VfFIyyqmbdfRGENHsL4wcg96nw0F3x0fgjz5Jkn5N3zF3NqMIMMNwHlWq0qBxAZJatkjk4Jt0oLQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5223 X-Mailman-Approved-At: Tue, 18 Jan 2022 09:48:37 +0100 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --_000_SN6PR05MB489540C7514CE53DF7A1BB3EB1589SN6PR05MB4895namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable @Stephen Hemminger This is process priva= te as the tap fds are maintained in per process data structures. In existin= g scheme, the fds are opened by the primary during queue setup and exchange= d to during secondary probe where the send_msg using SOL_SOCKET and SCM_RIG= HTS would remap the corresponding fds to the secondary process. If the seco= ndary process is coming up once the primary is initialised things would wor= k fine, but it's a problem during hotplug of the tap device. Thanks, Param. ________________________________ From: Stephen Hemminger Sent: 18 January 2022 03:46 To: Kumara Parameshwaran Cc: keith.wiles@intel.com ; dev@dpdk.org ; Kumara Parameshwaran Subject: Re: [PATCH] net/tap: Bug fix to populate fds in secondary process On Fri, 26 Nov 2021 09:45:15 +0530 Kumara Parameshwaran wrote: > + ret =3D rte_eth_dev_get_port_by_name(request_param->port_name, &por= t_id); > + if (ret) { > + TAP_LOG(ERR, "Failed to get port id for %s", > + request_param->port_name); > + return -1; > + } > + dev =3D &rte_eth_devices[port_id]; > + process_private =3D dev->process_private; > + dev->data->nb_rx_queues =3D request_param->rxq_count; > + dev->data->nb_tx_queues =3D request_param->txq_count; Why is this necessary? dev->data is already in memory shared between prima= ry and secondary process. --_000_SN6PR05MB489540C7514CE53DF7A1BB3EB1589SN6PR05MB4895namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
@Stephen Hemminger&nb= sp;This is process private as the tap fds are maintained in per process dat= a structures. In existing scheme, the fds are opened by the primary during queue setup and exchanged to during secondary= probe where the send_msg using SOL_SOCKET and SCM_RIGHTS would remap = the corresponding fds to the secondary process. If the secondary process is= coming up once the primary is initialised things would work fine, but it's a problem during hotplug of the tap devic= e. 

Thanks,
Param. 
From: Stephen Hemminger <= ;stephen@networkplumber.org>
Sent: 18 January 2022 03:46
To: Kumara Parameshwaran <kumaraparamesh92@gmail.com>
Cc: keith.wiles@intel.com <keith.wiles@intel.com>; dev@dpdk.or= g <dev@dpdk.org>; Kumara Parameshwaran <kparameshwar@vmware.com>= ;
Subject: Re: [PATCH] net/tap: Bug fix to populate fds in secondary p= rocess
 
On Fri, 26 Nov 2021 09:45:15 +0530
Kumara Parameshwaran <kumaraparamesh92@gmail.com> wrote:

> +     ret =3D rte_eth_dev_get_port_by_name(request= _param->port_name, &port_id);
> +     if (ret) {
> +           &nb= sp; TAP_LOG(ERR, "Failed to get port id for %s",
> +           &nb= sp;         request_param->port_= name);
> +           &nb= sp; return -1;
> +     }
> +     dev =3D &rte_eth_devices[port_id];
> +     process_private =3D dev->process_private;=
> +     dev->data->nb_rx_queues =3D request_pa= ram->rxq_count;
> +     dev->data->nb_tx_queues =3D request_pa= ram->txq_count;

Why is this necessary?  dev->data is already in memory shared betwe= en primary
and secondary process.
--_000_SN6PR05MB489540C7514CE53DF7A1BB3EB1589SN6PR05MB4895namp_--