On Tue, Aug 8, 2017 at 12:30 PM, John Fastabend <john.fastab...@gmail.com> wrote: > On 08/08/2017 10:04 AM, Tom Herbert wrote: >> On Tue, Aug 8, 2017 at 8:31 AM, John Fastabend <john.fastab...@gmail.com> >> wrote: >>> On 08/07/2017 10:28 AM, Tom Herbert wrote: >>>> Generalize the ULP infrastructure that was recently introduced to >>>> support kTLS. This adds a SO_ULP socket option and creates new fields in >>>> sock structure for ULP ops and ULP data. Also, the interface allows >>>> additional per ULP parameters to be set so that a ULP can be pushed >>>> and operations started in one shot. >>>> >>>> In this patch set: >>>> - Minor dependency fix in inet_common.h >>>> - Implement ULP infrastructure as a socket mechanism >>>> - Fixes TCP and TLS to use the new method (maintaining backwards >>>> API compatibility) >>>> - Adds a ulp.txt document >>>> >>>> Tested: Ran simple ULP. Dave Watson verified kTLS works. >>>> >>>> -v2: Fix compilation errors when CONFIG_ULP_SOCK not set. >>>> -v3: Fix one more build issue, check that sk_protocol is IPPROTO_TCP >>>> in tsl_init. Also, fix a couple of minor issues related to >>>> introducing locked versions of sendmsg, send page. Thanks to >>>> Dave Watson, John Fastabend, and Mat Martineau for testing and >>>> providing fixes. >>>> >>> >>> >>> Hi Tom, Dave, >>> >>> I'm concerned about the performance impact of walking a list and >>> doing string compares on every socket we create with kTLS. Dave >>> do you have any request/response tests for kTLS that would put pressure >>> on the create/destroy time of this infrastructure? We should do some >>> tests with dummy entries in the ULP list to understand the impact of >>> this list walk. >>> >>> I like the underlying TCP generalized hooks, but do we really expect a >>> lot of these hooks to exist? If we only have two on the roadmap >>> (kTLS and socktap) it seems a bit overkill. Further, if we really expect >>> many ULP objects then the list walk and compare will become more expensive >>> perhaps becoming noticeable in request per second metrics. >>> >>> Why not just create another socktap socketopt? That will be better from >>> complexity and likely performance sides. >>> >> IMO, given that there is at most two even proposed at this point I >> don't there's much point addressing performance. When ULP feature >> catches on and we start see a whole bunch of them then it's >> straightforward to use a hash table or some more efficient mechanism. >> > > OTOH these optimizations are usually easiest to do at the beginning. And > building an enum of ULP types would allow removing string comparisons and > to do simpler unsigned comparisons. I wont complain too much here though > because this series didn't introduce the lists. > Hi John,
It's a tradeoff. The nice thing about using strings is that we don't need maintain a universal enum. A related problem is how to combine different ULPs on the same socket. For instance, I might want to do filtering on the application layer messages being sent over TLS (stap+kTLS ULPs). So far I don't see an obvious way to do that. The buffering requirement for crypto seems to convolute this some. Tom
