lkml.org 
[lkml]   [2008]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator
    David Miller wrote:
    > From: Roland Dreier <rdreier@cisco.com>
    > Date: Sat, 09 Aug 2008 22:14:11 -0700
    >
    >
    >> > Also, I find it ironic that the port abduction is being asked for in
    >> > order to be "compatible with existing tools" yet in fact this stuff
    >> > breaks everything. You can't netfilter this traffic, you can't apply
    >> > qdiscs to it, you can't execut TC actions on them, you can't do
    >> > segmentation offload on them, you can't look for the usual TCP MIB
    >> > statistics on the connection, etc. etc. etc.
    >>
    >> We already support offloads that break other features, eg large receive
    >> offload breaks forwarding. We deal with it.
    >>
    >
    > We turn it off. If I want to shape or filter one of these iSCSI
    > connections can we turn it off?
    >
    >
    Sure.

    Seems to me we _could_ architect this all so that these devices would
    have to support a method for the management/admin tools to tweak, and if
    nothing else kill, offload connections if policy rules change and the
    existing connections aren't implementing the policy. IE: if the offload
    connection doesn't support whatever security or other facilities that
    the admin requires, then the admin should have the ability to disable
    that device. And of course, some devices will allow doing things like
    netfilter, qos, tweaking vlan tags, etc even on active connection, if
    the OS infrastructure is there to hook it all up.

    BTW: I think all these offload devices provide MIBs and could be pulled
    in to the normal management tools.


    Steve.


    \
     
     \ /
      Last update: 2008-08-10 20:01    [W:5.161 / U:0.560 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site