Cathy Zhou wrote:
>>> Further, again, as I said, aggregation should be able to work at the
>>> same time when fast-path is used. aggr call mac_open() too.
>>
>> Maybe I'm missing something, but as far as I know, aggregations can't
>> work with IP interfaces also plumbed, fast-path or no fast-path.
>> They're both active mac clients. mac_open() should just plain fail
>> with EBUSY for aggregations regardless.
>>
> Aggregation cannot use fast-path but it can work together with
> fast-path. E.g, when both IP and aggregation is used over ce and, IP can
> still use fast-path without problem.
This configuration is not valid. If IP is plumbed over ce0, I should not be
able to create an aggregation that includes ce0, and vice versa. Example
using bge1:
bash-3.2# ifconfig bge1
bge0: flags=201004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4,CoS> mtu 1500
index 2
inet 10.8.57.38 netmask ffffff00 broadcast 10.8.57.255
ether 0:3:ba:94:31:96
bash-3.2# dladm create-aggr -l bge1 -l bge1 myaggr0
dladm: create operation failed: link busy
...
bash-3.2# dladm create-aggr -l bge1 myaggr0
bash-3.2# ifconfig bge1 plumb
ifconfig: SIOCSLIFNAME for ip: bge1: Device busy
> But when VNIC is created over ce,
> IP has to fallback to slow-path to assure correct functionality.
Right, VNIC and passive MAC clients like snoop which need to see the packets.
Other than those two categories of MAC clients, I frankly cannot think of a
single mac client which can co-exist with IP, other than IP itself, which
should be able to work with the IP fast-path enabled.
-Seb
