From: "Juraj Linkeš" <juraj.linkes@pantheon.tech>
To: Jeremy Spewock <jspewock@iol.unh.edu>
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
Subject: Re: [PATCH 1/1] dts: add binding to different drivers to TG node
Date: Thu, 19 Sep 2024 11:10:12 +0200 [thread overview]
Message-ID: <119bc99b-d5ed-4dd8-8a02-41821ea0660f@pantheon.tech> (raw)
In-Reply-To: <CAAA20UTh3pF-3LFvXSn1Wme1v=s3N94r6VyuK2DtOSzq3ftjTQ@mail.gmail.com>
On 18. 9. 2024 20:50, Jeremy Spewock wrote:
> On Mon, Sep 16, 2024 at 6:04 AM Juraj Linkeš <juraj.linkes@pantheon.tech> wrote:
>>
>>
>>
>> On 9. 9. 2024 17:55, Jeremy Spewock wrote:
>>> On Mon, Sep 9, 2024 at 8:16 AM Juraj Linkeš <juraj.linkes@pantheon.tech> wrote:
>>>>
>>>>
>>>>
>>>> On 12. 8. 2024 19:22, jspewock@iol.unh.edu wrote:
>>>>> From: Jeremy Spewock <jspewock@iol.unh.edu>
>>>>>
>>>>> 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.
next prev parent reply other threads:[~2024-09-19 9:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 17:22 [PATCH 0/1] dts: add driver binding on TG jspewock
2024-08-12 17:22 ` [PATCH 1/1] dts: add binding to different drivers to TG node jspewock
2024-08-12 17:49 ` Nicholas Pratte
2024-09-09 12:16 ` Juraj Linkeš
2024-09-09 15:55 ` Jeremy Spewock
2024-09-16 10:04 ` Juraj Linkeš
2024-09-18 18:50 ` Jeremy Spewock
2024-09-19 9:10 ` Juraj Linkeš [this message]
2024-09-12 13:00 ` Patrick Robb
2024-09-19 18:16 ` [PATCH v2 0/1] dts: add driver binding on TG jspewock
2024-09-19 18:16 ` [PATCH v2 1/1] dts: add binding to different drivers to TG node jspewock
2024-09-24 9:12 ` Juraj Linkeš
2024-09-24 13:57 ` Jeremy Spewock
2024-09-24 14:03 ` Juraj Linkeš
2024-09-24 16:28 ` [PATCH v3 0/2] dts: add driver binding on TG jspewock
2024-09-24 16:28 ` [PATCH v3 1/2] dts: add symbolic link to dpdk-devbind script jspewock
2024-09-25 5:48 ` Juraj Linkeš
2024-09-27 11:49 ` Luca Vizzarro
2024-09-24 16:28 ` [PATCH v3 2/2] dts: add binding to different drivers to TG node jspewock
2024-09-25 6:01 ` Juraj Linkeš
2024-09-27 11:50 ` Luca Vizzarro
2024-09-30 13:42 ` [PATCH v3 0/2] dts: add driver binding on TG Juraj Linkeš
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=119bc99b-d5ed-4dd8-8a02-41821ea0660f@pantheon.tech \
--to=juraj.linkes@pantheon.tech \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=Luca.Vizzarro@arm.com \
--cc=alex.chapman@arm.com \
--cc=dev@dpdk.org \
--cc=jspewock@iol.unh.edu \
--cc=npratte@iol.unh.edu \
--cc=paul.szczepanek@arm.com \
--cc=probb@iol.unh.edu \
--cc=thomas@monjalon.net \
--cc=wathsala.vithanage@arm.com \
--cc=yoan.picchi@foss.arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).