Learn source addresses with their ingress-port association
Learning builds an association from a received source address to the port on which that source was observed. In the KSZ8862M description, the lookup engine adds a qualified source that is not already present and stores the port and timestamp with it. The packet must meet the source's stated validity conditions. Learning therefore is not an unconditional insertion from every sequence of bits arriving at an interface.
The address being learned is the source, whereas a later forwarding decision concerns the destination. Keeping these subjects separate prevents the lookup-table description from becoming a claim that the device learns a new destination from every frame. A stored source association gives information about where that source has been seen; it is not yet the complete policy for sending a packet toward another station.
Migration addresses a changed observation of an existing source. Microchip describes updating the source-port information when a valid received packet identifies the known source on a different port. This is dynamic state maintenance based on traffic, rather than a fixed physical-port identity inferred from a board label. No table capacity, programming command or observed migration result is supplied here.
Retain ageing as dynamic-state maintenance
A learned association also has a time dimension. The KSZ8862M account refreshes a record's timestamp when the corresponding source address appears. That continuing observation is different from creating the association initially. A record can therefore retain the same address and port relationship while its age is updated by subsequent qualifying traffic.
Ageing uses that timestamp to remove stale dynamic entries when they are not refreshed over the described interval. The record is consequently not a permanent statement that the same station will always be reached through the same port. Migration and ageing address different changes: one updates an observed port relationship, while the other removes information that has not been renewed.
Preserving this distinction explains why a previous lookup observation cannot stand in for lasting configuration evidence. The source also treats ageing as a configurable feature of the named device, so a capability description does not establish its present setting. This qualitative account adopts no timeout or control bit. It explains traffic-maintained state without reporting a current table, a retained configuration or a network observation from an offered controller.
Separate lookup results from forwarding policy and filtering
Forwarding begins with a different address subject. Microchip's prose describes a destination lookup involving the relevant tables, followed by additional policy processing that modifies the forwarding result. The first lookup outcome is therefore not the complete delivery decision. Learning where a source was observed does not remove these later responsibilities or prove that any particular destination will receive a frame.
The source separately identifies traffic that is not forwarded, including erroneous packets, pause frames handled for flow control and packets whose destination lookup resolves back to their ingress port. These are different reasons for retaining traffic locally rather than moving it onward. A broad switch-function description should not reduce them to one unexplained success or failure state.
These distinctions can be preserved from the prose without interpreting the document's forwarding flowcharts. The named policy stages and filtering categories explain why a lookup association is only part of the path. This account supplies no VLAN rule, register recipe, throughput or latency value. It also does not transfer the KSZ8862M feature description to every Ethernet switch IC or establish completed forwarding on a board.
Keep host packet queues separate from the wire-side switch
The Queue Management Unit has another boundary: packet traffic between the MAC/PHY side and the system host. Microchip describes separate transmit and receive queues with packet storage, control information, status and host notification. That responsibility is different from the autonomous source-learning and destination-forwarding functions associated with traffic moving through the switch.
A host transmit queue also carries information about the frame being submitted, rather than being only an undifferentiated block of packet bytes. The source separates frame control, length and data in its introductory queue description. These different responsibilities explain why host-side queue support needs its own interface and status context. It is not simply a count of external wire-side ports.
Keeping the host path separate also avoids promoting an IC capability into a complete board result. The existence of queues supplies no evidence about the offered board's populated connectors, driver, firmware or present packet transfer. Likewise, basic learning and queue management do not imply the TSN time-distribution and traffic-service mechanisms covered by the related architecture guide. No bus-pin decoding, queue-size value or driver sequence is adopted here.
Sources and further reading
Microchip DS00003324A, 2020, KSZ8862-16M/-32M: bounded learning/migration/ageing/forwarding prose on physical pages 23–25 and QMU introduction on page 31. Flowcharts, table programming, capacity/latency values, TSN inclusion and actual board/driver results are excluded.