em: remove M_HASHTYPE when RSS is not enabled

[cc]

Summary

Since "73fe85e486d2 tcp: store flowid info in syncache", inp_flowid can be set
if the incoming packet is not M_HASHTYPE_NONE. But this can introduce dummy
and duplicated flowid when a virtual interface set M_HASHTYPE_OPAQUE. This
change will let the upper layer know how to deal with software hash, with
benefits like inp_flowid can be set correctly and m_pkthdr.flowid can be set
correctly in output path.

This fix is similar to "20285cad7a55"

Test Plan

command: iperf3 -c macfbsd16git -t10 -b 1K -P2 -VZ

Tested in a FreeBSD 16-current VM hosted by VMware Fusion in Apple arm64.

before change:

cc@macfbsd16git:~ % netstat -nRp tcp
Active Internet connections
Proto     Recv-Q Send-Q Local Address          Foreign Address           flowid ftype
tcp4           0      0 192.168.xx.xx.5201     192.168.xx.xx.51312     e2770000    63
tcp4           0      0 192.168.xx.xx.5201     192.168.xx.xx.51311     e2770000    63
tcp4           0      0 192.168.xx.xx.5201     192.168.xx.xx.51310     e2770000    63
tcp4           0      0 192.168.xx.xx.22       192.168.xx.xx.51182     e2770000    63
cc@macfbsd16git:~ %

after change:

cc@macfbsd16git:~ % netstat -nRp tcp
Active Internet connections
Proto     Recv-Q Send-Q Local Address          Foreign Address           flowid ftype
tcp4           0      0 192.168.xx.xx.5201     192.168.xx.xx.51322     366f5cf1   130
tcp4           0      0 192.168.xx.xx.5201     192.168.xx.xx.51321     6dbeadc8   130
tcp4           0      0 192.168.xx.xx.5201     192.168.xx.xx.51320     ff200c19   130
tcp4           0      0 192.168.xx.xx.22       192.168.xx.xx.51317     56c2aa36   130
cc@macfbsd16git:~ %

[kbowling]

Looking at the linked change.. em can have two queues in one hw case. Does it matter?

[kbowling]

qemu can emulate it as 'e1000e' https://github.com/qemu/qemu/blob/master/hw/net/e1000e.c

[cc]

In D55137#1260492, @kbowling wrote:

Looking at the linked change.. em can have two queues in one hw case. Does it matter?

My understanding is that if only one rx queue, RSS is not needed, so no hash value is needed. In a case of two rx queues, does not the hw enable RSS and provide RSS hash values?

[kbowling]

In D55137#1260494, @cc wrote:

In D55137#1260492, @kbowling wrote:

Looking at the linked change.. em can have two queues in one hw case. Does it matter?

My understanding is that if only one rx queue, RSS is not needed, so no hash value is needed. In a case of two rx queues, does not the hw enable RSS and provide RSS hash values?

I think that jives with pg.140: http://iommu.com/datasheets/ethernet/controllers-nics/intel/e1000/82574.pdf, the stipulation being we are seeing '0' in an error case and also no hw RSS?

igb_txrx might need the same fix

[cc]

In D55137#1260582, @kbowling wrote:

In D55137#1260494, @cc wrote:

In D55137#1260492, @kbowling wrote:

Looking at the linked change.. em can have two queues in one hw case. Does it matter?

My understanding is that if only one rx queue, RSS is not needed, so no hash value is needed. In a case of two rx queues, does not the hw enable RSS and provide RSS hash values?

I think that jives with pg.140: http://iommu.com/datasheets/ethernet/controllers-nics/intel/e1000/82574.pdf, the stipulation being we are seeing '0' in an error case and also no hw RSS?

igb_txrx might need the same fix

Thanks for the review and recommendation! Created the fix for igb_txrx in https://reviews.freebsd.org/D55143