Mike Ditto Wrote:
David Edmondson wrote:
If we go the way you propose, it seems that snoop could see a variety
of packets that are not accepted for transmission by the driver.
This would be very confusing for an administrator.
2. For xen case, when domUs are communicating with each other, does
it make sense to cut the virtual link when the packet can't go
through the
physical link?
I don't follow this comment, sorry.
The case here is when the bridge forwards a packet from a Xen DomU to
the physical link interface that (Dom0) IP is plumbed on. If the driver
is unable to transmit packets because of hardware problems or link
failure, should we start dropping packets that the Xen DomU is sending
to Dom0? I don't think so, although the right behavior here is not
obvious. By generalizing the loopback behavior we are effectively
extending the topology of the link. When there are two users of a
datalink provider, we consider them to be like two nodes on the link,
and there are situations where they are able to talk to each other even
while there is a failure elsewhere on the link and some other nodes are
unreachable. This is analagous to having a small hub on your desk,
connecting your laptop and desktop to the central switch in a distant
computer room. If the link to the computer room fails, you still want
your laptop and desktop machines to be able to communicate with each
other.
But I had forgotten about the queueing aspects. When the driver's
transmit buffers are full, it returns some packets unprocessed,
allowing the caller to queue them until the hardware is ready. In
that case it's wrong to loop them back to snoop or any other user
unless we can arrange for them to be queued without being looped back
again later.
D'oh!
I guess this logic does have to be changed.
I agree.
Unfortunately, it seems to require holding onto a dup of every packet
while the driver makes its transmit attempt, as opposed to the
loopback-first approach which avoids the dup unless somebody actually
needs a copy.
Looks like our "save-one-copy" approach is unsuitable here. :-(
-=] Mike [=-
Best,
Donghai.
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
