Re: [RFC 0/0] Introducing a generic socket offload framework

On Fri, Aug 19, 2011 at 5:49 AM, jamal [off-list ref] wrote:

On Thu, 2011-08-18 at 15:07 -0700, San Mehat wrote:

quoted

TL;DR
-----
In this RFC we propose the introduction of the concept of hardware socket
offload to the Linux kernel. Patches will accompany this RFC in a few

days,

quoted

but we felt we had enough on the design to solicit constructive

discussion

quoted

from the community at-large.

[..]

quoted

ALTERNATIVE STRATEGIES
----------------------

An alternative strategy for providing similar functionality involves

either

quoted

modifying glibc or using LD_PRELOAD tricks to intercept socket calls. We

were

quoted

forced to rule this out due to the complexity (and fragility) involved

with

quoted

attempting to maintain a general solution compatible across various
distributions where platform-libraries differ.

Above should have been in your TL;DR;->

LD_PRELOAD is also horrible because of the granularity of the socket
calls;
Having things in the kernel and specifically tagging socket as needing
this feature is much much more manageable.

Tying things to virtualization may miss the big picture because there
are many other use cases for intercepting socket calls, example:
Samir Bellabes [off-list ref] has been trying to get what he refers to
as "personal firewall" (equivalent to the silly windows firewall) which
prompts the user "ping from blah, do you want to allow a response?"
That requires intercepting send/recv calls, prompt the user in possibly
some pop-up and act based on response. It requires looking at content.
He is trying to use selinux for that interface,
but i think this would be the right abstraction.

I agree; there's no reason this needs to be tied to virtualization - it was
just the
driving force behind the design. I will generalize the backend interface
types

I hope you plan to support send/recv.

yes

I also hope you add support for SOCK_RAW (and maybe SOCK_PACKET).

 Can you explain a good use-case for SOCK_RAW in this type of environment?
We were noodling it around locally and couldn't come up with one that we
needed to support.

Q: If you want this to be transparent to the apps, who/what is doing

the tagging of SOCK_HWASSIST? clearly not the app if you dont want to
change it.

 The decision of whether to tag a socket or not is made by the 'hardware'

I like the uri abstraction if it doesnt come at the expense of the

app transparency.

Thank you,

-san

cheers,
jamal

-- 
San Mehat | Staff Software Engineer | san@google.com | 415-366-6172