Re: [PATCH v3 1/1] dts: bind to DPDK driver before running test suites

[Jeremy Spewock <jspewock@iol.unh.edu>]

[-- Attachment #1: Type: text/plain, Size: 2752 bytes --]

On Tue, Nov 14, 2023 at 4:49 PM Thomas Monjalon <thomas@monjalon.net> wrote:

> 13/11/2023 18:56, Patrick Robb:
> > On Thu, Nov 9, 2023 at 6:17 PM <jspewock@iol.unh.edu> wrote:
> >
> > > From: Jeremy Spewock <jspewock@iol.unh.edu>
> > >
> > > Modifies the current process so that we bind to os_driver_for_dpdk from
> > > the configuration file before running test suites and bind back to the
> > > os_driver afterwards. This allows test suites to assume that the ports
> > > are bound to a DPDK supported driver or bind to either driver as
> needed.
> > >
> > > Signed-off-by: Jeremy Spewock <jspewock@iol.unh.edu>
> > >
> > > We discussed this aspect of binding during last week's CI meeting and I
> > understood Juraj to be consenting to returning to DTS running the binding
> > to the dpdk driver (so, what you're doing here), as opposed to relying on
> > the user to do it, and making it a smoke test. As we've discussed, that's
> > how the old DTS framework ran, and I prefer to stick to this approach.
> One
> > aspect I raised was how in a lab context it's desirable for us to define
> as
> > much as possible within config files, and have environmental
> configuration
> > be handled by DTS. So, since there was basically agreement here, I think
> > your changes here are appropriate.
> >
> > Acked-by: Patrick Robb <probb@iol.unh.edu>
>
> Not sure it is a good idea to add something knowing it will be reworked,
> but you agreed, so I apply.
>
>

I believe logically the methods I am adding here wouldn't end up needing to
be refactored, the refactor part would be of the already existing logic in
the TGNode to allow for it to be able to use the method I wrote here. There
are a few things that would need to change if we wanted to be able to
support doing this on the TGNode because the current framework doesn't
exactly allow for it since the devbind script doesn't exist on that node.
The main reason I refrained from doing that rework in this patch is due to
the lack of need for the support of it on the TGNode at this time (and
potentially in the future) and the lack of existing support.

The methods I am writing here however would likely not need to be reworked,
just moved to their superclass if we decided we wanted to do the TGNode
rework and add support. Apologies if I made it sound like I was submitting
these changes just for them to be completely overridden and changed in the
near future and hopefully that makes a little more sense.

Thank you for applying!



> PS: please make all versions of the same patch in the same email thread.
>

I will start doing this in future patches, sorry for any difficulty it may
have caused trying to see previous comments.

[-- Attachment #2: Type: text/html, Size: 4141 bytes --]