Fixed comments by cperciva@ that I got via email since I blocked accidentally comments here

llq_config->llq_num_decs_before_header =

• ENA_ADMIN_LLQ_NUM_DESCS_BEFORE_HEADER_2;

+ ENA_ADMIN_LLQ_NUM_DESCS_BEFORE_HEADER_2;

No reason for this whitespace change? The original 4 spaces is style(9) conformant since this is a long-line-wrapping indent.

+ /* If the user didn't specify regular LLQ explicitly */
+ use_large_llq = (ena_force_large_llq_header !=
+ ENA_LLQ_HEADER_SIZE_POLICY_REGULAR);
+
+ /* The device supports large LLQ */
+ use_large_llq &= !!(llq->entry_size_ctrl_supported &
+ ENA_ADMIN_LIST_ENTRY_SIZE_256B);
+
+ /* If the user set no preference, check if the device recommends */
+ if (ena_force_large_llq_header == ENA_LLQ_HEADER_SIZE_POLICY_DEFAULT)
+ use_large_llq &= (llq->entry_size_recommended ==
+ ENA_ADMIN_LIST_ENTRY_SIZE_256B);

I'm not really a fan of using &= on bools, especially in multiple stages like this. I would write this with a switch (ena_force_large_llq_header) followed by if (!(...supported & ...SIZE_256B)) use_large_llq = false; since that seems to capture the intent more clearly?

(Also, I *assume* the device will never recommend 256B while not supporting it, but putting the "supported" test last is probably safer and certainly
clearer.)

If there's a strong preference within Amazon for the code style you used, I'm ok with it (FreeBSD is big on "play nice with upstreams"!) but if there's no particular reason for doing it this way then I think it could be improved.

Patch [1] ...
[1] - See Fixes
Fixes: 0a33c047a443 ("ena: Support LLQ entry size recommendation from
device")

I know every problem in computer science can be solved by adding more layers of indirection, but this seems unnecessary. How about just starting the commit message with "Commit 0a33c047a443 introduced new values to hw.ena.force_large_llq_header." ? (Definitely keep the Fixes: trailer though.)

Colin Percival

Added default: clause to switch to handle case of illegal values set to force_large_llq_header