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 ACF21A034C; Tue, 18 Jan 2022 17:21:48 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 535394273A; Tue, 18 Jan 2022 17:21:48 +0100 (CET) Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by mails.dpdk.org (Postfix) with ESMTP id 380584068E for ; Tue, 18 Jan 2022 17:21:47 +0100 (CET) Received: by mail-pl1-f180.google.com with SMTP id d7so3464394plr.12 for ; Tue, 18 Jan 2022 08:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=LthhFF1iQY/gRytbEUPYCHaT/X9tQHvu1wAxHbRZWFk=; b=7SQhZZJntmqK5qNmAO51ZQdvjCjoXyzswlu6kD9rVZkQJoRMieiZ149AaIdoCL8O3n BceEjXvmChRNUsFSQKx5TO+wW1Nja8O8YVCgcQADwfgc1pd6nycHGeTLahEgv3KAwAtP jdCiSrl3+fJP98DobykzUoW/MobG2XhiJoSB959u7iHZdd2UgRDD70DiHL2GwCw4AnYx bhzU21kDS2lwAvEH+mnyRwkJkBzVOVLiO0mvmorsou8HXgZSp8gDCf3iEO/nLp1h5SJ1 rz72Z1F0cNY8ewnbjbSkYznBYGE5lUT0o2Xuc2Rs6iOTg0OBdh2dw+VV9fiQMb+Xj6Nq nYEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=LthhFF1iQY/gRytbEUPYCHaT/X9tQHvu1wAxHbRZWFk=; b=xVkKHhJomUGozM95thyGy52dAnvbcOWGHpS4HErmNUPSshGVoQ/wkT60LDOHrifzSK S0hHHNjqpHHXQBarsJI6jreVuBB0+jvX/ZZAnF7ZjwtFGy6ydKtO9Kc8HVjamAiS0FC+ Zks3QOJWTma7+xDCe3vt2yz8RYjMb89pEDTkiQeBARfi00dNMnf0oLzy4xZ9t7wMbulh pkvdLXDAT4sdRcJeTw/giE7x9OlJl53ooykBeWkIISBzrpg99TBtF8MBA6Ek0FihGq96 ghQnCXHVLQJYHtJN2SzEa9FBbZ/W+tCPqV1CeV1msYclyRfpwEDsPlZ9TO/uhWb8LAme z45w== X-Gm-Message-State: AOAM532erSOwqMdNQZy7xZ1QlBTN4IXoHN7lR1p3RIqKm3WPFYBYRmwh 2DotoWwDngK/t/hioWMuG0yNTg== X-Google-Smtp-Source: ABdhPJxTVop2b9DPdy5vj0SThR/RFu73yCcSnJKnFI8q0TJw56HkGEcAVXnGgLQuZvLUTDflUMx5mQ== X-Received: by 2002:a17:902:a501:b0:14a:4ed2:2a01 with SMTP id s1-20020a170902a50100b0014a4ed22a01mr27678312plq.49.1642522906390; Tue, 18 Jan 2022 08:21:46 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id om15sm3269705pjb.46.2022.01.18.08.21.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Jan 2022 08:21:46 -0800 (PST) Date: Tue, 18 Jan 2022 08:21:43 -0800 From: Stephen Hemminger To: Kumara Parameshwaran Cc: Kumara Parameshwaran , "keith.wiles@intel.com" , "dev@dpdk.org" Subject: Re: [PATCH] net/tap: Bug fix to populate fds in secondary process Message-ID: <20220118082143.0eedf2b5@hermes.local> In-Reply-To: References: <20211126041515.96259-1-kumaraparamesh92@gmail.com> <20220117141655.2a375448@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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 ; 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.