[Tfug] Ethernet frame "immutables" wrt switch silicon

[Bexley Hall]

Hi Louis,

On 5/12/2013 1:25 PM, Louis Taber wrote:
> Almost all switches today are dual/triple/quad rate.  Which means the
> switch must have the capability to store and forward.  The switch might
> also have the destination interface in use when another packet starts
> arriving for the same out-going interface.  So, even if all of the
> interfaces are the same speed the switch can be forced into a store and
> forward mode.

Yes.  As such, the switch must be able to *understand* the
structure of the frames it handles.  But, only to the extent that it
can know/determine the size of the frame and where it has to go
(as well as from whence it came).

I don't think that it is a requirement that a switch be able to verify
the frame's integrity.  I.e., a switch should (??) be able to propagate
a "bad frame" (bad CRC, etc.).  This is particularly true if the frame
can cut through -- since it hasn't yet seen the entire "original" frame
and can't, therefore, pass judgement on whether it is a *good* frame or
not.

[Should a switch be able to *fix* a bad CRC when it retransmits??]

> At a minimum, if the switch can do a cut through, it will
> need to see the destination MAC address prior to sending the packet
> forward.

There still is buffering present in a cut through -- it's just
not "deferred" to the extent that it might otherwise be (e.g.,
in the case where the destination port is busy at the time).

> Does anyone know of a switch that can do a cut through on
> broadcast packets to available ports while using a store and forward
> strategy for the remaining interfaces?  - Louis

Conceivable but I'm not sure it buys you much.  I.e., even if
the broadcast packet is stored on the "open" ports, it will
be dispatched RSN (though not as quickly as if cut through).

OTOH, I can't see why a switch wouldn't do this as a natural
consequence of its design -- it decides whether to cut through
or store based on how busy the destination i/f is... why would
it not use a similar algorithm when processing an incoming broadcast
packet?  I.e., "get this packet out *your* port as soon as it
makes sense to you..." (regardless of what the other ports are
doing, now)

I don't think any switches are "stupid" enough (??) to busy *all*
ports to ensure broadcasts are timed coincidentally from each
of them.

[I'd have to think on this a bit more for PTP-aware fabric]