Skip to content

Conversation

@shreyaskunder
Copy link
Contributor

Related-To: VLCLJ-2678

Related-To: VLCLJ-2678

Signed-off-by: Shreyas Kunder <shreyas.kunder@intel.com>
Related-To: VLCLJ-2678

Signed-off-by: Shreyas Kunder <shreyas.kunder@intel.com>
Related-To: VLCLJ-2678

Signed-off-by: Shreyas Kunder <shreyas.kunder@intel.com>
Related-To: VLCLJ-2678

Signed-off-by: Shreyas Kunder <shreyas.kunder@intel.com>
EXPECT_EQ(ZE_RESULT_NOT_READY,
zetMetricTracerReadDataExp(metric_tracer_handle, &raw_data_size,
nullptr))
raw_data.data()))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should check that raw_data_size is 0 on return


LZT_TEST_F(
zetMetricTracerTest,
GivenTracerIsEnabledWhenQueryingForDataSizeWithZeroSizeThenExpectInvalidArgumentError) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor: some minor rewarding.
"GivenTracerIsEnabledWhenQueryingForDataSizeThenExpectInvalidArgumentError" . No need to say withZeroSize.

Ideally, for clarity, can add a comment saying something in the lines of "tracer read data does not allow querying for available size "

LOG_DEBUG << "synchronize with completion of workload";
lzt::synchronize(command_queue, std::numeric_limits<uint64_t>::max());

size_t raw_data_size = 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please confirm, but I suspect this test does not need to run any workload. Since it is just an API param check.

LZT_TEST_F(
zetMetricTracerTest,
GivenTracerIsEnabledWhenRequestingMoreRawDataThanAvailableThenReturnOnlyWhatIsAvailable) {
/* When allocating a larger buffer than needed, ensure that writes happen only
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems this test does not make sense any more since you cannot know how much size is available.
Instead seems there should be a test that sets a small buffer and confirms can read multiple times, concatenate data and call calculate and data is valid. This will be the most used case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants