David Miller wrote:
From: Roland Dreier <rdreier@xxxxxxxxx>
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
