Remove duplicate RSS hash recalculation code.

[btw]

Summary

Previously, I didn't notice that RSS hash has already been recalculated
explicitly by rss_mbuf_software_hash_v4() in ip_reass() which is same
as what rss_soft_m2cpuid_v4() does, so it is okay to use rss_m2cpuid()
in ip_direct_nh. Sorry! >_<...

But I still think it is better to use rss_soft_m2cpuid_v4() to recalculate
the RSS hash instead of calling rss_mbuf_software_hash_v4() directly in
ip_reass(). Because it could maximize code reuse, and it won't introduce
additional overhead. So this patch removes the explicit RSS hash
recalculation code in ip_reass().

Test Plan

I have done a simple test based on the tools here [1].

First, I enabled UDP 4-tuple hashing to make sure the RSS hash
is recalculated as the type of RSS_HASHTYPE_RSS_UDP_IPV4 or
RSS_HASHTYPE_RSS_UDP_IPV6 by np_m2cpuid (for testing purpose).

diff --git a/sys/net/rss_config.c b/sys/net/rss_config.c
index e7e8eb4..320ed9b 100644
--- a/sys/net/rss_config.c
+++ b/sys/net/rss_config.c
@@ -483,14 +483,14 @@ rss_gethashconfig(void)
 	return (
 	    RSS_HASHTYPE_RSS_IPV4
 	|    RSS_HASHTYPE_RSS_TCP_IPV4
+	|    RSS_HASHTYPE_RSS_UDP_IPV4
 	|    RSS_HASHTYPE_RSS_IPV6
 	|    RSS_HASHTYPE_RSS_TCP_IPV6
+	|    RSS_HASHTYPE_RSS_UDP_IPV6
 	|    RSS_HASHTYPE_RSS_IPV6_EX
 	|    RSS_HASHTYPE_RSS_TCP_IPV6_EX
 #if 0
-	|    RSS_HASHTYPE_RSS_UDP_IPV4
 	|    RSS_HASHTYPE_RSS_UDP_IPV4_EX
-	|    RSS_HASHTYPE_RSS_UDP_IPV6
 	|    RSS_HASHTYPE_RSS_UDP_IPV6_EX
 #endif
 	);

Then, I used pktgen to generate UDP packets with the UDP payload
length varies in the range of 100 to 10000 bytes (packets will be
fragmented by pktgen when the payload exceeds 800 bytes), but
keep the 4-tuple (saddr, sport, daddr, dport) consistent, and inject
them into tap(4). So the flowid of each packet received by rss-udp-srv
should be the same even if the packet is fragmented.

% sudo ./pktgen -i tap0 -4 -n 100000 -l 100   # No fragment, 100000 packets
% sudo ./pktgen -i tap0 -4 -n 100000 -l 1000  # 2 fragments, 100000 packets
% sudo ./pktgen -i tap0 -4 -n 100000 -l 10000 # 13 fragments, 100000 packets

% ./rss-udp-srv/rss-udp-srv 0
starting: tid=0, rss_bucket=0, cpuid=0
starting: tid=1, rss_bucket=1, cpuid=1
starting: tid=2, rss_bucket=2, cpuid=2
starting: tid=3, rss_bucket=3, cpuid=3
[0] th=0x801615400
starting: tid=4, rss_bucket=4, cpuid=0
[3] th=0x801615580
starting: tid=5, rss_bucket=5, cpuid=1
starting: tid=6, rss_bucket=6, cpuid=2
starting: tid=7, rss_bucket=7, cpuid=3

[2] th=0x801615500
[7] th=0x801615780
[6] th=0x801615700
[4] th=0x801615600
[1] th=0x801615480
[5] th=0x801615680


count(flowid=0eb93bce)=100000 
count(flowid=0eb93bce)=100000 
count(flowid=0eb93bce)=100000 
count(flowid=0eb93bce)=120252 
count(flowid=0eb93bce)=198590 
count(flowid=0eb93bce)=200000 
count(flowid=0eb93bce)=200000 
count(flowid=0eb93bce)=200885 
count(flowid=0eb93bce)=211979 
count(flowid=0eb93bce)=223108 
count(flowid=0eb93bce)=234176 
count(flowid=0eb93bce)=245255 
count(flowid=0eb93bce)=256331 
count(flowid=0eb93bce)=267407 
count(flowid=0eb93bce)=278462 
count(flowid=0eb93bce)=289584 
count(flowid=0eb93bce)=300000 
count(flowid=0eb93bce)=300000 
^C

% netstat -s -p ip | grep -E '(fragments|reassembled)'
        1500000 fragments received
        0 fragments dropped (dup or out of space)
        0 fragments dropped after timeout
        200000 packets reassembled ok
        0 fragments created

300000 packets were received. All packets had the same flowid (RSS hash).
It is the expected result.

[1] https://github.com/btw616/ip6_direct_test

[btw]

Remove some obsolete comments about the flowid of directly dispatched frames.
Now the flowid of directly dispatched frames will be recalculated by
rss_soft_m2cpuid_v4() if needed. So there is no such assumption any more.