In D54605#1247812, @brooks wrote:

In D54605#1247657, @erj wrote:

In D54605#1247601, @brooks wrote:

For additional context, I took a look at the disassembly on amd64 and the memsets are all expanded in place:

Did you look at the assembly from before the change and did it look like the post-memset change contents? I'm curious about what that custom zeroing code looked like and what it achieved.

It's bit hard to tease out, but it looks like the compiler might be slightly better at dead store elimination with the open-coded version. In particular rxd_init_zero expands to:

;               ri_pad->rxd_val[i] = 0;
ffffffff80cf98ad: 48 c7 85 58 ff ff ff 00 00 00 00      movq    $0x0, -0xa8(%rbp)
;               ri_pad->rxd_val[i + 3] = 0;
ffffffff80cf98b8: 48 c7 85 70 ff ff ff 00 00 00 00      movq    $0x0, -0x90(%rbp)
;       ri_pad->rxd_val[RXD_INFO_SIZE - 1] = 0;  
ffffffff80cf98c3: 48 c7 85 78 ff ff ff 00 00 00 00      movq    $0x0, -0x88(%rbp)

where the i + 1 and i + 2 statements are eliminated.

If this really matters we should find a more maintainable solution.

I like the idea.

In D54605#1247601, @brooks wrote:

For additional context, I took a look at the disassembly on amd64 and the memsets are all expanded in place:

This has been sitting for about a month -- does it need more changing or testing?

In D52782#1210730, @kgalazka wrote:

In D52782#1206718, @erj wrote:

Can you tell us what the hardware enhancements are? 👀

I added a bit more details.

(approval for the functionality; you should make @ziaee's suggested changes to the documentation)

Can you tell us what the hardware enhancements are? 👀

I think the automatic close fails if the diff is too big or has too many files? It's happened a lot to me, but I never figured out why. So as @kbowling says, it's not cutting corners, it's just an imperfect integration between git and Phabricator; it's normal to make small edits between the review being approved and pushing it upstream.

This all seems sensible to me.

I think it's ok as-is, but there are some future changes to look at.

I'm not familiar with QAT hardware, so these comments are mostly about documentation and trying to understand some of it a bit better.

In the description:

In D48812#1148812, @jhb wrote:

Do we still need this after fixing the PCI bus driver to stop caching the message count?

Cancelling a 4 port SFP OCP card sounds like an odd move to me.

It looks good to me, with the added newline

I'm going to assume there are some hidden #ifdefs that are getting stripped out that require the write() function to be more complex for some reason. @krzysztof.galazka_intel.com ?

I can now confirm that the I226-K doesn't need any extra changes to work properly; it links at 2.5G and DHCP works:

This means that the PSH and FIN flag correctly appear only in the last segment, but the CWR flag does not only appear in the first segment, but also in all middle segments.
Using this patch, this could be fixed.

When doing Accurate ECN as currently being specified in Accurate ECN, the masks should be:

mask.first	0xFF6
mask.middle	0xFF6
mask.last	0xFFF

The proposed patch would allow a NIC to be configured to do TSO for either classical ECN or accurate ECN.

Does this description make the motivation clear?

@Yogesh.Bhosale_intel.com I forgot to change the commit header to have you as the author; I'll fix that if/when I do the MFC.

In D46187#1053418, @zlei wrote:

In D46187#1052954, @erj wrote:

ixl(4) and ice(4) could integrate this function, too:

ixl(4) needs to remove the unused "vsi->oqdrops" variable and just not handle the IFCOUNTER_OQDROPS case in its switch statement in ixl_if_get_counter(), then call your new iflib_if_get_counter_default().

"vsi->oqdrops" is actually in use. It is set via IXL_SET_OQDROPS in function ixl_update_vsi_stats().