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 9F21045A03; Tue, 24 Sep 2024 16:03:06 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2D6E940274; Tue, 24 Sep 2024 16:03:06 +0200 (CEST) Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by mails.dpdk.org (Postfix) with ESMTP id C22A1400D5 for ; Tue, 24 Sep 2024 16:03:04 +0200 (CEST) Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a8d4093722bso465185966b.0 for ; Tue, 24 Sep 2024 07:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.tech; s=google; t=1727186584; x=1727791384; 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=r/Cs4OMQB3ksktEeOU836rTyxMvTrw6jIdMbNM4LOgA=; b=P5w0mt8BoL525EIOzKz9xLJ/Rs/yvxWCKTm3ND2GjVjsUGcESLeWyahsqBbJhudLHv LVAf0h3fP8wKy9C9LxYiCl2Dnkhft+tyhp4DNo5QneVFYC5a+DsatMGsT1HNKfTv/QR1 lCaE6HA3G4lV4CoP5hfrY5lN5PCeZ4nufZW7KysywpaRK1t4RaNzPrt5WyjVeCYWF7c8 6KAaPOX21yHEU7unefyc9dA6WjLYhryhWahvc8gZkwhyld2leShy761tOSTZ4qWz6js0 vtY9EYkazEATvJVVM1GKS8EVDJUYRHnMaBbaECruhA+EyaiCpLjo+Ku79RiJGUUQZVKh 987Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727186584; x=1727791384; 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=r/Cs4OMQB3ksktEeOU836rTyxMvTrw6jIdMbNM4LOgA=; b=v9shq5Pc0tC0Ghzn1Ng/7uTdz9sXZAIWGR/oCe3nfhrJcovx49XjNz1lWx85cti15W plvkVxEjh8FJY45EWkD3lsGv++HseydF4Eezi4x9twKejUMwIvdUsI7G1zJ50grxB5qV 9lyS2fPqC3upTDy6bXQ8Pn2pD6OXsQThc2l/hVjU8gcpMMVkMi2sQ7UgvvjVY3djI1DK o4gKfDOKO3gV2k75XDkpTMsvvZtjOeD/5oN4GUOo/jvlrKKm/kwefE1cUE+0HcRg93h0 ndvTdoSMXsQdbEwJ02gsxcbquHMardHUN1eTOg60DokaVQt9CnQuI00Y5DEkycxgQOW/ TS1A== X-Forwarded-Encrypted: i=1; AJvYcCW430pApvUipvifaNcEzVIqkM7b+PENaF+x3IMgek+EL8ZgEeSFXY2+z0vfjaNxSXrJ4yQ=@dpdk.org X-Gm-Message-State: AOJu0Yzxy0r+1Hvt5E2Fz2XLUzeYezq2pXS7FpxznrmBaYHSC32Akubk QNZg/izYswrzuDqMOPhMqYzYMmlTKylRk4fKOResJYgcnNi9e4XtDk+MA5ZNRdM= X-Google-Smtp-Source: AGHT+IGDCwgRm02MfFFP3+YGbAUBzFF6htgC6IkW/osrHGKIcg//ZZ3sQrhjKn7ifHFi2QfcYzT2Xw== X-Received: by 2002:a17:907:e28a:b0:a86:79a2:ab12 with SMTP id a640c23a62f3a-a90d56e8c49mr1516693966b.38.1727186584146; Tue, 24 Sep 2024 07:03:04 -0700 (PDT) Received: from [192.168.200.22] ([84.245.121.62]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9392f32db2sm88942866b.25.2024.09.24.07.03.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Sep 2024 07:03:03 -0700 (PDT) Message-ID: Date: Tue, 24 Sep 2024 16:03:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] dts: add binding to different drivers to TG node To: Jeremy Spewock Cc: alex.chapman@arm.com, npratte@iol.unh.edu, thomas@monjalon.net, Honnappa.Nagarahalli@arm.com, probb@iol.unh.edu, yoan.picchi@foss.arm.com, Luca.Vizzarro@arm.com, paul.szczepanek@arm.com, wathsala.vithanage@arm.com, dev@dpdk.org References: <20240812172251.41131-1-jspewock@iol.unh.edu> <20240919181611.20289-1-jspewock@iol.unh.edu> <20240919181611.20289-2-jspewock@iol.unh.edu> <0eeacec2-6b17-4ed6-8444-c3963378b7f5@pantheon.tech> 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 24. 9. 2024 15:57, Jeremy Spewock wrote: > On Tue, Sep 24, 2024 at 5:12 AM Juraj Linkeš wrote: >> >> I have some thoughts for the future: >> 1a. The traffic generator is specified per-node, so maybe we could also >> change the binding to be for the whole lifetime of the TG node, >> 1b. But the same is true for the SUT node as well, right? After we do >> the port update (with kernel driver), we can just bind to DPDK driver. >> With SUT in the mix, this looks like a change for a different patch, > > Right, these are good points. A good observation too that we only > really need the kernel driver at the start in both cases. You had > mentioned in your previous comments as well that we should only be > binding on the TG once per lifetime, but I ended up not adding it for > that very reason of I still wanted the binding to be in Node, but I > didn't want to change the process for the SUT. > >> 2. We could add a symlink to the devbind script with the target being in >> the dts directory. This way we don't have to go outside the dts >> directory and if DTS ever become a python package, we could just copy >> the script to the appropriate place. This is also something we don't >> really need to do. > > I like this idea a lot actually. It feels very weird to me having to > step out of the DTS directory and I like the idea of keeping it > together like it were a package (even if it isn't yet). > Ok, you can add that to the next version. >>> diff --git a/dts/framework/testbed_model/node.py b/dts/framework/testbed_model/node.py >> >>> @@ -58,8 +65,10 @@ class Node(ABC): >>> lcores: list[LogicalCore] >>> ports: list[Port] >>> _logger: DTSLogger >>> + _remote_tmp_dir: PurePath >>> _other_sessions: list[OSSession] >>> _test_run_config: TestRunConfiguration >>> + _path_to_devbind_script: PurePath | None >> >> A note on the naming. We have _remote_tmp_dir and >> _path_to_devbind_script. Both are pointing to a remote file/dir, but >> only one has the _remote prefix. They should probably be unified. > > I didn't think of this but you're right, the two are very similar but > named differently. > >> >> I've thought a bit about what the right name is. Dropping the prefix >> makes sense; sut_node.tmp_dir should mean the tmp dir on the SUT node >> (which would make it remote from the execution host's point of view, but >> not the node's view; the file is local to SUT node). This could be a >> good separate patch (improving the remote/local naming scheme to make it >> consistent and as sensible as possible). > > I also like the sound of it without the prefix and how it actually has > a more fitting meaning from the two perspectives. I agree that there > is probably some other work to be done on this in another patch, but > since I am moving the _remote_tmp_dir variable around anyway I think > it wouldn't hurt for me to rename it. > Yes, we should pick one naming convention to be consistent in this patch and we can have a broader (framework-wide) look at this in a separate patch.