[PATCH 1/1] dts: add binding to different drivers to TG node

[Juraj Linkeš]

On 18. 9. 2024 20:50, Jeremy Spewock wrote:
> On Mon, Sep 16, 2024 at 6:04 AM Juraj Linkeš <juraj.linkes at 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 at pantheon.tech> wrote:
>>>>
>>>>
>>>>
>>>> On 12. 8. 2024 19:22, jspewock at iol.unh.edu wrote:
>>>>> From: Jeremy Spewock <jspewock at 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.