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 9D154A00C3; Tue, 18 Jan 2022 11:52:23 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2C77642703; Tue, 18 Jan 2022 11:52:23 +0100 (CET) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) by mails.dpdk.org (Postfix) with ESMTP id C46C44068E for ; Tue, 18 Jan 2022 11:52:21 +0100 (CET) Received: by mail-io1-f52.google.com with SMTP id v6so24947286iom.6 for ; Tue, 18 Jan 2022 02:52:21 -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=4lL5iRzSFo1iZumy9m0X4VU9fsG/gIZj+pZMREhlUgQ=; b=BM3RuxuCMHX3WwPA5alv12v1MJLFD9O6TA5xnLi3IJ98nRBZzjJ4uaRIlMKA4FXofv ZGAS1TxXkhr5nNA/YX7K3QOJUanBDRhkAEySqB8ZOfSqVGbhZW2RVMN+0xIVoXuLG6BE nPi4y8jpiZarYzzzIptt5sJYhVwkWbUh5nl1NM2iMegntUKcJ/0PylSELkcHHRCdhIFW jwMoSLRc9qu7WMjrbfHzzt2etb2j8W5YM13Q6uxuygMpCyVuDiZtEj/fd5inRUSGJegj dAez5EZSr/Ny1QipPkxapGE4wVBZgciIq0BPauAU8zxvoj3qQfAEwKir0Vu2TxGQCpXb zRHw== 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=4lL5iRzSFo1iZumy9m0X4VU9fsG/gIZj+pZMREhlUgQ=; b=YX1FFl963bmhuTHp567MtcvGuFH/0kpdwvbVu5t8CCtqVWIwXWjNYbYgxnXstTylxx dCqIp9+OWYiMqdD/4JrUcP29zN16mMHwei8Uqrbeu55T53zBLzpanyljyQA798hdD7+x PIwgXlYampaQOpHT3iyLwZNHSzUf5yFKBhsYE+sntJv/E1PQFFr//hsSZagYvzYbxcD1 oQK3drnl8WnICpReXfxN7baRI1tUnDcJoTfhEX3cGFYqb2nUHuJQC9HF3zfEt5IVuDyO Mub62Im/rD9eWl05+Xis3RFdrsmrZ0sjCVwBT4izmkAOCcJN0YSYI3yIon5xhFWvGNux CmjA== X-Gm-Message-State: AOAM531C4CNnBeQQcjZby++6jKW0qkX1IvhzVLbeYqBIJ+KMsgl/oeWg VWVn2eMspRaC535dvOxip9EPPvVziCH335P2Frk= X-Google-Smtp-Source: ABdhPJzzkCjmnzJRKUjtIWV0uN6j7g/XaGBPs+6wHrSbyhEdvJorsHx6sOZZb5rqV7hSp4FkdZVUyKYRbd+sX3pQaEo= X-Received: by 2002:a02:962d:: with SMTP id c42mr3714427jai.118.1642503141044; Tue, 18 Jan 2022 02:52:21 -0800 (PST) MIME-Version: 1.0 References: <20211126041515.96259-1-kumaraparamesh92@gmail.com> <83fe377d-adfe-76ca-5bbb-4f02f8575380@intel.com> In-Reply-To: From: kumaraparameshwaran rathinavel Date: Tue, 18 Jan 2022 16:22:09 +0530 Message-ID: Subject: Re: [PATCH] net/tap: Bug fix to populate fds in secondary process To: Ferruh Yigit Cc: Kumara Parameshwaran , "keith.wiles@intel.com" , "dev@dpdk.org" , Raslan Darawsheh Content-Type: multipart/alternative; boundary="00000000000043b69c05d5d910cc" 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 --00000000000043b69c05d5d910cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, even I was confused if it had been the tap_intr_handle_set function. In general the tap_dev_start should not be invoked by the secondary and only primary should do it. I referred it to a couple of PMDs and that was the case. Please let me know if I am missing something in my understanding. On Tue, Jan 18, 2022 at 2:40 PM Ferruh Yigit wrote= : > On 1/18/2022 4:39 AM, Kumara Parameshwaran wrote: > >> static int > >> tap_dev_start(struct rte_eth_dev *dev) > >> { > >> int err, i; > >> > >> + tap_mp_req_on_rxtx(dev); > >> + > > > > As for as I understand your logic is primary sends the message to the > secondar(y|ies), > > so what happens first secondary is started? > > =E2=80=8BIn case of TAP PMD looks like there is an assumption where pri= mary > should be started first. There is an existing check below during the prob= e > function call. > > if (!rte_eal_primary_proc_alive(NULL)) { > > TAP_LOG(ERR, "Primary process is missing"); > > return -1; > > } > > > > What about secondary sends the message when they are started? > > =E2=80=8BIMHO, since primary process setups the queue it should be suff= icient > for the primary processes to the send the message and secondary need not > send anything. > > > > Also above functions is called by both primary and secondary, what > happens when it is > > called by secondary? And the logic is not clear, it can be good to add = a > process type > > check to clarify. > > =E2=80=8BSure, these are for tap_intr_handle_set and tap_dev_start func= tions? > > I was thinking within the 'tap_dev_start()' function, for > 'tap_mp_req_on_rxtx()' call. > > Not sure how 'tap_intr_handle_set()' is involved, am I missing something. > --00000000000043b69c05d5d910cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, even I was confused if it=C2=A0 had been the tap= _intr_handle_set function.

In general the tap= _dev_start should not be invoked by the secondary and only primary should d= o it. I referred it to a couple of PMDs and that was the case. Please let m= e know if I am missing something in my understanding.

<= /div>
O= n Tue, Jan 18, 2022 at 2:40 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
On 1/18/2022 4:39 AM, Kumara Parameshw= aran wrote:
>>=C2=A0=C2=A0 static int
>>=C2=A0=C2=A0 tap_dev_start(struct rte_eth_dev *dev)
>>=C2=A0=C2=A0 {
>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int err, i;
>>=C2=A0 =C2=A0
>> +=C2=A0=C2=A0=C2=A0=C2=A0 tap_mp_req_on_rxtx(dev);
>> +
>
> As for as I understand your logic is primary sends the message to the = secondar(y|ies),
> so what happens first secondary is started?
> =E2=80=8BIn case of TAP PMD looks like there is an assumption where pr= imary should be started first. There is an existing check below during the = probe function call.
> if (!rte_eal_primary_proc_alive(NULL)) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0TAP_LOG(ERR, "Primary process is missin= g");
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return -1;
> }
>
> What about secondary sends the message when they are started?
> =E2=80=8BIMHO, since primary process setups the queue it should be suf= ficient for the primary processes to the send the message and secondary nee= d not send anything.
>
> Also above functions is called by both primary and secondary, what hap= pens when it is
> called by secondary? And the logic is not clear, it can be good to add= a process type
> check to clarify.
> =E2=80=8BSure, these are for tap_intr_handle_set and tap_dev_start fun= ctions?

I was thinking within the 'tap_dev_start()' function, for 'tap_= mp_req_on_rxtx()' call.

Not sure how 'tap_intr_handle_set()' is involved, am I missing some= thing.
--00000000000043b69c05d5d910cc--