On Thu, Sep 23, 2021 at 10:35:37AM +0300, Dmitry Kozlyuk wrote: > 2021-09-08 15:14 (UTC-0700), Jie Zhou: > > On Tue, Sep 07, 2021 at 09:43:56AM -0400, Aaron Conole wrote: > > > Jie Zhou <j...@linux.microsoft.com> writes: > > > > > > > Enable a subset of unit tests on Windows. Currently not all the > > > > dependencies (e.g. libraries and some functionalities) of all unit > > > > tests are supported on Windows yet. > > > > > > > > Signed-off-by: Jie Zhou <j...@linux.microsoft.com> > > > > --- > > > > > > Hi Jie, > > > > > > How is it expected that a developer will add unit tests here? For > > > example, let's pretend I develop some new test. Do I insert it into the > > > non-windows section or the 'all' section? Will it ever be moved common > > > (for example, do windows development team aim to provide some additional > > > test / review cycles for new tests added)? This have some implication > > > on how developers need to add tests - maybe there can be a documented > > > process for getting code more common (between windows / linux / > > > freebsd)? > > > > > > -Aaron > > > > > > PS: I would suggest a possible route is to update to the doc proposed in > > > http://patches.dpdk.org/project/dpdk/patch/20210714164047.511561-1-acon...@redhat.com/ > > > but it still isn't merged. > > > > Thank you Aaron for bringing up this great question! Totally agree that we > > need some discussion on what is the expectation for onboarding new unit > > tests from different OS teams. For new tests that definitely missing > > supports on certain OS(s), should it be authored in a way for across all > > OSs but skip not supported ones at the beginning? Or just onboard for > > supported OS thus only add to the non-windows section for example, and > > later DPDK Windows team move it to common section after porting? I will > > bring this up in DPDK Windows Community meeting and discuss there first. > > Yes, we should update the doc (after your change merged) on the process > > once reaching some agreement. > > Hi Aaron, Jie, > > Currently tests that should not run on certain platforms are disabled with > #ifdef. This has an advantage that these tests mark themselves as skipped. > There are no principal objections against this approach instead of many lists. > Many tests files will need to be modified, but only mechanically. > > New tests for generic features should be cross-platform by default; why not? > An exception I can think of is EAL that may implement some new API only for > one OS. In this case the best we can do is to make sure the test code is not > inherently bound to some OS. This is something we can document. For example, > it should use <rte_ip.h> instead of including Unix network headers directly.
Thank you Dmitry. I will address this in V4 to use consolidated lists across all platforms. Aaron, please let me know if any other comments or concerns I can address together in V4. Thanks.
