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 697EDA0352; Wed, 19 Jan 2022 05:34:03 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 126244068A; Wed, 19 Jan 2022 05:34:02 +0100 (CET) Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) by mails.dpdk.org (Postfix) with ESMTP id 48D914013F for ; Wed, 19 Jan 2022 05:34:01 +0100 (CET) Received: by mail-il1-f178.google.com with SMTP id u5so1120342ilq.9 for ; Tue, 18 Jan 2022 20:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+7fps5eejDrsR7CCgna/ZMs7pMnIdm0qUiYsSnG3Sbs=; b=fMXd8SHe29QNHZy3biR9Ixp+hwhSzZC2YhaOXA1E50SBC1pvUxn8ELRdK1xrbvyGzz HZyD+LCMa8rmd5zDp+SWRf+oRpgBl/fdDns7zhzaRXpKzn48IlOIDjm6CoL0323J2k+a jAOmaRlfJoxc9y8XkGnNLpEtFsJIMSiQ10BwKzgIp57CPHGd0tfht8bJ1QiM9P8QuAdk lYFuQR0QbgNFZDwXaoAc9MxSDNDCV03ZhTrGcQOnZPFmZTBEmspsGbd6GzntMZ5vJ24b sy6K5RA8d2jSTpTN8BHF1qi9qjc7X3zo2KVn0IR3C50rExJepqG9b4Q4NsyTOgWiz8QH hnoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+7fps5eejDrsR7CCgna/ZMs7pMnIdm0qUiYsSnG3Sbs=; b=O76TSv7VexPRXPPh8jGIfsWmy2enkzgDj+aZZ+Eg+NeM/hpMFL/1Iy5LePvZBITU8n JJqHbMv6YHUasJcrPFjlWzHC6ihuJ3mPf27ZUCcxBbO8gLxq30QlOfXDHWDhgcIpDQJv kcO1Cyi7rxm1+0b1VTEtkT/VKDtYnH9ygqt0Vg4/OOL5UNQ+J3cN9ED1aX4aUdPoURho 3qSTpwlXoEtTz+VzYPWnaeeFHhG7qoDpQgr0SzwN/GmwzjEi52LprijTT4HrLji08nbc s4gRjtyNH5wzTpz8xqJ6Jve4j3+xDJewu2xeokR0ZnQ4TpvVWhSzWVgJ8jy+0TeqQGQw MQCg== X-Gm-Message-State: AOAM530OqX41Q5ZtjFqv43qfv08ekYCL8CtzpV8pMFZTVI2UlQX9vNrR ntH6Xr1GV1lcEYTSleNgD4GTTddJCBXZ6sc9ow0= X-Google-Smtp-Source: ABdhPJxzh77WWKkpQwVNA7QGyg33Ks3n0OdxbWE5m16ZsAxDDbQkO5K0164zP2NnRTjT6+1QUsVIZJjZePP8hmGaMgE= X-Received: by 2002:a05:6e02:1548:: with SMTP id j8mr3359905ilu.104.1642566840511; Tue, 18 Jan 2022 20:34:00 -0800 (PST) MIME-Version: 1.0 References: <20211126041515.96259-1-kumaraparamesh92@gmail.com> <20220117141655.2a375448@hermes.local> <20220118082143.0eedf2b5@hermes.local> In-Reply-To: <20220118082143.0eedf2b5@hermes.local> From: kumaraparameshwaran rathinavel Date: Wed, 19 Jan 2022 10:03:49 +0530 Message-ID: Subject: Re: [PATCH] net/tap: Bug fix to populate fds in secondary process To: Stephen Hemminger Cc: Kumara Parameshwaran , "keith.wiles@intel.com" , "dev@dpdk.org" Content-Type: multipart/alternative; boundary="0000000000000c6f6a05d5e7e572" 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 --0000000000000c6f6a05d5e7e572 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 18, 2022 at 9:51 PM Stephen Hemminger < stephen@networkplumber.org> wrote: > On Tue, 18 Jan 2022 05:22:19 +0000 > Kumara Parameshwaran wrote: > > > @Stephen Hemminger This is process > private as the tap fds are maintained in per process data 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 device. > > > > Thanks, > > Param. > > ________________________________ > > From: Stephen Hemminger > > Sent: 18 January 2022 03:46 > > To: Kumara Parameshwaran > > Cc: keith.wiles@intel.com ; dev@dpdk.org < > 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 = rte_eth_dev_get_port_by_name(request_param->port_name, > &port_id); > > > + if (ret) { > > > + TAP_LOG(ERR, "Failed to get port id for %s", > > > + request_param->port_name); > > > + return -1; > > > + } > > > + dev = &rte_eth_devices[port_id]; > > > + process_private = dev->process_private; > > > + dev->data->nb_rx_queues = request_param->rxq_count; > > > + dev->data->nb_tx_queues = request_param->txq_count; > > > > Why is this necessary? dev->data is already in memory shared between > primary > > and secondary process. > > > The question is about the two assignments that happen in secondary proces > > that change dev->data->nb_rx_queues and dev->data->nb_tx_queues. These > are > > shared and should not need to be modified here. > Sure my bad. Misunderstood the comment. Yes, this should not be done, will remove the assignments. --0000000000000c6f6a05d5e7e572 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 18, 2022 at 9:51 PM Steph= en Hemminger <stephen@netw= orkplumber.org> wrote:
On Tue, 18 Jan 2022 05:22:19 +0000
Kumara Parameshwaran <kparameshwar@vmware.com> wrote:

> @Stephen Hemminger<mailto:stephen@networkplumber.org> This is process p= rivate as the tap fds are maintained in per process data structures. In exi= sting scheme, the fds are opened by the primary during queue setup and exch= anged 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 device.
>
> Thanks,
> Param.
> ________________________________
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: 18 January 2022 03:46
> To: Kumara Parameshwaran <kumaraparamesh92@gmail.com>
> Cc: keith.w= iles@intel.com <keith.wiles@intel.com>; dev@dpdk.org <dev@dpdk.org>; Kumara Parameshwaran <kparameshwar@vmware.com> > Subject: Re: [PATCH] net/tap: Bug fix to populate fds in secondary pro= cess
>
> On Fri, 26 Nov 2021 09:45:15 +0530
> Kumara Parameshwaran <kumaraparamesh92@gmail.com> wrote:
>
> > +=C2=A0 =C2=A0 =C2=A0ret =3D rte_eth_dev_get_port_by_name(request= _param->port_name, &port_id);
> > +=C2=A0 =C2=A0 =C2=A0if (ret) {
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TAP_LOG(ERR, &qu= ot;Failed to get port id for %s",
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0request_param->port_name);
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -1;
> > +=C2=A0 =C2=A0 =C2=A0}
> > +=C2=A0 =C2=A0 =C2=A0dev =3D &rte_eth_devices[port_id];
> > +=C2=A0 =C2=A0 =C2=A0process_private =3D dev->process_private;=
> > +=C2=A0 =C2=A0 =C2=A0dev->data->nb_rx_queues =3D request_pa= ram->rxq_count;
> > +=C2=A0 =C2=A0 =C2=A0dev->data->nb_tx_queues =3D request_pa= ram->txq_count;=C2=A0
>
> Why is this necessary?=C2=A0 dev->data is already in memory shared = between primary
> and secondary process.

> The question is about the two assignments that happen in secondary= proces
> that change dev->data->nb_rx_queues and dev->data-= >nb_tx_queues.=C2=A0 These are
> shared and should not need to be = modified here.
=C2=A0Sure my bad. Misunderstood the co= mment. Yes, this should not be done, will remove the assignments.=C2=A0
--0000000000000c6f6a05d5e7e572--