UDP transmit and no flowid

[Eugene Grosbein]

On 05.03.2014 04:11, Adrian Chadd wrote:
> Hi,
> 
> On 4 March 2014 04:14, Eugene Grosbein <egrosbein at rdtc.ru> wrote:
>> On 04.03.2014 08:17, Adrian Chadd wrote:
>>
>>> I'll try this out in the next week or two once I've sorted out my
>>> employment situation and I can reserve some time on the netperf
>>> cluster.
>>
>> There is a patch written by melifaro at freebsd.org to introduce
>> IP flow id generation and modified by me to add sysctl
>> net.inet.ip.skip_flowid_gen to disable id generation in run time
>> and return pre-patched behavior:
>>
>> http://www.grosbein.net/freebsd/patches/netisr_ip_flowid.diff
>>
>> I've tested it in production for mpd5-based high loaded BRAS, it works just fine.
>> It uses IP src/dst addresses and TCP/UDP/SCTP ports to feed jenkins_hashword()
>> and to fill m->m_pkthdr.flowid.
> 
> Hm, is this actually going to work for all paths through ip_output?
> Only a couple of paths go via netisr_queue(); the rest go via
> ifp->if_output. Is that going to loop back through the netisr outbound
> path?
> 
> For some workloads we'll want to fill this in with the topelitz hash
> that matches the RX flow from the NIC, just to keep locking/processing
> of that flow on the same core.
> 
> And to answer Slawa's email - yes, mainly because it's a subset of
> what's needed for doing this for TCP. In the TCP case, the hashing is
> already done for us on inbound connections; but there's still the
> whole missing bits from Robert's work to tie in the pcbgroup handling
> and the whole multi-queue / multi-listener thing that Linux and now
> DragonflyBSD does.
> 
> But there's a handful of silly things that need to be first
> investigated and checked - like, ensuring that it works fine with
> fragmented IP frames and re-encapsulated things - just to ensure that
> they don't break the RSS model.
> 
> Why'd you have to do an m_pullup() here in this path, which ideally
> should just be a lookup only path? Are you actually seeing the IP/TCP
> headers spread across multiple mbufs? They're not being snuck into
> mbuf headroom at all?

I cannot answer these questions, CC'ing author of the patch, Alexander Chernikov.

Eugene Grosbein