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. > Tom > >> Thanks, >> .John >>
