On 05/01/2018 13:41, Eugene Grosbein wrote:
05.01.2018 16:34, Steven Hartland wrote:
I hope there's some improvements that can be made, for example if we can
determine
the stream was instigated remotely then flowid would always be valid hence we
can use it assuming it
matches the requested spec or if we can make it clear to the user that
laggproto is not the one they requested, I'm open to ideas?
We just need to clear flow id from incoming TCP segments and always generate
new flow id for responses
keeping old flow id for IP forwarding case. Please back out your change to not
degrade IP forwarding performance.
Sorry I don't follow you. You seem to be inferring that we can easily generate
a flowid without involving the sending hardware
RSS has nothing to do with sending hardware. It's operating system's job to
choose outgoing port, not hardware's job.
The OS is deciding which outgoing, however its using the hash based on
the flowid to do so, which is only valid after the first rx hence the
problem; as this results in the hash calculation being different for the
first packet.
I can't see how that is possible as that's chicken and egg i.e. you can't get
the HW interface
to generate the flowid without sending a packet and you can't send a packet
until you have a the flowid to decide which interface to send it from.
Outgoing packet flow does not and should not depend on incoming flow,
they are independent things in case of LACP. There is no "chicken and egg"
problem at all.
But this is how it works ATM, it uses the flowid which is only valid
after the first rx.
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
