On (05/03/17 14:11), Paul Wouters wrote: > >See other mail about entropy. Everything that uses flow-based > >parallelism (RSS at the host, ECMP at the switches) needs to be able to > >spread flows across multiple paths, while making sure there is > >no packet reordering within the flow. > > > >having as much granularity in the flow-id as possible is the key > >to getting this to work well. > > So you want to use the SPI's to spread the flows. Okay, I guess I > understand that now, and that it is not an entropy source or something.
Yes, I want to use the SPI as a flow-identiifer, in much the same way that the TCP or UDP 4-tuple is used as a flow identifier today. >From the definition of SA, SPI and PFP in RFC 4301 there is no architectural conflict about using a 32 bit spi in the same way that the (sport, dport) pair in TCP/UDP are used for flow-hashing. > It seems using IKE to artificially split up an IPsec SA into multiple > ones to address a kernel issue is not the proper solution though. I just want PFP support as defined in RFC 4301 (and yes, there is a valuable use-case for it). As I mentioned to you offline, let me take some time to look at the technical suggestions you made about missing kernel pieces and see what we can do about this. Please give me some time to parse all that useful information.. --Sowmini _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
