lkml.org 
[lkml]   [2011]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RFC 0/0] Introducing a generic socket offload framework
    From
    On Fri, Aug 19, 2011 at 5:49 AM, jamal <hadi@cyberus.ca> wrote:
    >
    > On Thu, 2011-08-18 at 15:07 -0700, San Mehat wrote:
    > > 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,
    > > but we felt we had enough on the design to solicit constructive discussion
    > > from the community at-large.
    > >
    >
    > [..]
    >
    > > ALTERNATIVE STRATEGIES
    > > ----------------------
    > >
    > > An alternative strategy for providing similar functionality involves either
    > > modifying glibc or using LD_PRELOAD tricks to intercept socket calls. We were
    > > forced to rule this out due to the complexity (and fragility) involved with
    > > 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 <sam@synack.fr> 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
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-08-19 17:01    [W:0.061 / U:61.164 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site