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 142A2459D3; Thu, 19 Sep 2024 11:10:17 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D4192402B1; Thu, 19 Sep 2024 11:10:16 +0200 (CEST) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by mails.dpdk.org (Postfix) with ESMTP id E9B95400D5 for ; Thu, 19 Sep 2024 11:10:14 +0200 (CEST) Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-5365cf5de24so774116e87.1 for ; Thu, 19 Sep 2024 02:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.tech; s=google; t=1726737014; x=1727341814; darn=dpdk.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=6I2X4FzmZhFcDOZ7S5XdaXwKDr9cE09cfS+4VVFHR30=; b=t0EiK6hXhPzSy0V1Bw9oWCjtwaJmhOH2xXzPxJXSa6GxlB1RRHvwriG3zhqp11XW7D 0vgTCfM5CjRWd/xm5mW75wH66pLjqVs7HAh4XgAjL3V8iIQOUN1twN9QZ0iWwJFFdX/C Sw5ixfBHxUaXEwTEpoqdISdcuKTjLNew9csBKMkBvwosYD32HKnGD18LggyZ3cchQ4Eg tdTASAq4RFrimiHhpZxYSFOC61zLiRCevE587C9qAkCDCWhEYzDp3pOLVb0AM9ZWwPNM wmavlB+7e+Knx2rdBas/n78rEOcdxulnfMLYGnbIE4ApfXlhMYDuGGQy1SYiy9AKsakW PQ+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726737014; x=1727341814; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6I2X4FzmZhFcDOZ7S5XdaXwKDr9cE09cfS+4VVFHR30=; b=V4SzCGmeAT3BwJi6jp9VuhqWKE5Y68bZ63r42POxeD/6pH4QVHY10eEsR8vsrdG5tI Avz7XAxm/RWeRInSdOhQTqextcnsbIoanMcAMhl8j815xif8fw11F5HITIDUMdpjVcA3 lM46rGUgNNNoM6qpOEDeB90CG5GwORFHYSu2eDxlDNeQryqR+LS8rBzbq0DMAfVKAUEw +bFkUOZ40bAo9PTKE9wkwopZuRnoauoJ7VRoGxeiAJfIWu7/Dm7OUsDhfTrxM61RFbzK w9gGOHhYQ7L9ZI0U/mF+2SJqmSKVPuNpEbsYAeAG7enNNsmF7DSNMyPkKaWK23wqZk2m rQvg== X-Forwarded-Encrypted: i=1; AJvYcCVktg3T7CGfhlh/w56iPHLRTvhXXCpELa5N5bFdTBEmmaqDZNQ9HM3Nc5szDAoc9fwGqrc=@dpdk.org X-Gm-Message-State: AOJu0YzxDFAUUW+Sfby43DL2Xm+7C7OiF1mh/SD6n9v+1YSFUDtHcQhO CEtVKzGl+GyCaXkAsormWE0cmvyxGqK3ihOCP8kB2sPou9tiPiFLqn+qoavhiqI= X-Google-Smtp-Source: AGHT+IGwtsHq74qSbZoFgPRLroNloD2Lk9U7ZPr+rova4Pnw16pPHwyykxFafnfY5nG+1+dZa/m85A== X-Received: by 2002:a05:6512:68c:b0:533:4817:7280 with SMTP id 2adb3069b0e04-53678fc24dbmr14950485e87.35.1726737013971; Thu, 19 Sep 2024 02:10:13 -0700 (PDT) Received: from [192.168.200.22] ([84.245.121.62]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a906109676esm693445166b.33.2024.09.19.02.10.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Sep 2024 02:10:13 -0700 (PDT) Message-ID: <119bc99b-d5ed-4dd8-8a02-41821ea0660f@pantheon.tech> Date: Thu, 19 Sep 2024 11:10:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/1] dts: add binding to different drivers to TG node To: Jeremy Spewock Cc: alex.chapman@arm.com, Luca.Vizzarro@arm.com, wathsala.vithanage@arm.com, Honnappa.Nagarahalli@arm.com, paul.szczepanek@arm.com, npratte@iol.unh.edu, thomas@monjalon.net, yoan.picchi@foss.arm.com, probb@iol.unh.edu, dev@dpdk.org References: <20240812172251.41131-1-jspewock@iol.unh.edu> <20240812172251.41131-2-jspewock@iol.unh.edu> Content-Language: en-US From: =?UTF-8?Q?Juraj_Linke=C5=A1?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 18. 9. 2024 20:50, Jeremy Spewock wrote: > On Mon, Sep 16, 2024 at 6:04 AM Juraj Linkeš wrote: >> >> >> >> On 9. 9. 2024 17:55, Jeremy Spewock wrote: >>> On Mon, Sep 9, 2024 at 8:16 AM Juraj Linkeš wrote: >>>> >>>> >>>> >>>> On 12. 8. 2024 19:22, jspewock@iol.unh.edu wrote: >>>>> From: Jeremy Spewock >>>>> >>>>> The DTS framework in its current state supports binding ports to >>>>> different drivers on the SUT node but not the TG node. The TG node >>>>> already has the information that it needs about the different drivers >>>>> that it has available in the configuration file, but it did not >>>>> previously have access to the devbind script, so it did not use that >>>>> information for anything. >>>>> >>>>> This patch moves the steps to copy the DPDK tarball into the node class >>>>> rather than the SUT node class, and calls this function on the TG node >>>>> as well as the SUT. It also moves the driver binding step into the Node >>>>> class and triggers the same pattern of binding to ports that existed on >>>>> the SUT on the TG. >>>>> >>>> >>>> This is a very inefficient way to do this. We'll have to build DPDK >>>> twice and that's very time consuming. I was thinking in terms of just >>> >>> This patch shouldn't be compiling DPDK twice, are you referring to the >>> process of copying the tarball over and extracting it taking too long? >>> If so, that makes sense that it takes longer than we need for this one >>> task. I figured it wouldn't hurt to have the whole DPDK directory >>> there, and that it could even be potentially useful to have it if the >>> TG ever needed it. That and it seemed like the most straightforward >>> way that kept these two set up in a similar way. Extracting the >>> tarball is obviously pretty quick, so I guess the real question here >>> is whether it is fine to add the time of one extra SCP of the DPDK >>> tarball around. >>> >> >> Ah, I didn't look carefully at the split. This is fine, but there some >> things I noticed. >> >> As Patrick mentioned, the docstrings in Node.set_up_build_target() and >> SutNode.set_up_build_target() would need to be updated. >> Why are we binding ports on the TG node? > > I figured that the assumption would be that whatever is in the config > file is what the TG needs to be bound to in order to run the testing, > similarly to how we always bind on the SUT assuming that we need to be > using the DPDK driver to test DPDK. > Ah, I see. That makes sense now and we should do that. I was thinking a bit ahead. If we have two traffic generators, one for performance, one for functional testing, each using a different driver, we'd run into problems there. We're not there yet, so that's a problem that will need solving in a future patchset.