Lines Matching full:network
19 they configured/queried a switch port network device or a regular network
36 For each front-panel port, DSA creates specialized network devices which are
38 stack. These specialized network interfaces are referred to as "user" network
54 Note that DSA does not currently create network interfaces for the "cpu" and
62 cannot really be used as proper network interfaces either, only the
105 ``needed_tailroom`` properties are also used to request from the network stack,
120 From the perspective of the network stack, all switches within the same DSA
133 the network stack sees. This can be seen with Marvell switch trees, where the
162 mockup driver, which can be attached to any network interface. The goal is that
163 any network interface should be capable of transmitting the same packet in the
171 ``struct net_device *dev`` represents the virtual DSA user network interface
186 virtual DSA user network interface corresponding to the physical front-facing
209 to the network without a proper checksum (the checksum field will have the
224 Conduit network devices
227 Conduit network devices are regular, unmodified Linux network device drivers for
232 drivers. Such network devices are also often referred to as conduit network
246 Conduit network device (e.g.: e1000e):
275 - locate per-port network device
276 - invoke ``eth_type_trans()`` with the DSA user network device
279 Past this point, the DSA user network devices get delivered regular Ethernet
282 User network devices
285 User network devices created by DSA are stacked on top of their conduit network
286 device, each of these network interfaces will be responsible for being a
296 These user network devices have custom net_device_ops and ethtool_ops function
300 Upon frame transmission from these user network devices, DSA will look up which
301 switch tagging protocol is currently registered with these network devices and
305 These frames are then queued for transmission using the conduit network device
327 Summarized, this is basically how DSA looks like from a network device
388 the conduit network device this switch tree is attached to needs to be
391 - ``dsa_switch_tree``: structure assigned to the conduit network device under
399 a ``dsa_switch_tree`` as a backpointer, user network devices, conduit network
408 Lack of CPU/DSA network devices
411 DSA does not currently create user network devices for the CPU or DSA ports, as
426 Once a conduit network device is configured to use DSA (dev->dsa_ptr becomes
427 non-NULL), and the switch behind it expects a tagging protocol, this network
447 User network devices exposed by DSA may or may not be interfacing with PHY
479 of per-port user network devices. As of today, the only SWITCHDEV objects
499 the non-user ports too, which are invisible to iproute2 because no network
630 configure the switch to separate all network interfaces from each other, that
686 - ``adjust_link``: Function invoked by the PHY library when a user network device
705 return their values. DSA overlays user network devices general statistics:
706 RX/TX counters from the network device, with switch driver specific statistics
712 function may for certain implementations also query the conduit network device
754 - ``port_enable``: function invoked by the DSA user network device ndo_open
760 - ``port_disable``: function invoked by the DSA user network device ndo_close
1032 and team drivers, which are modeled as virtual, stackable network interfaces.
1075 Normally an MRP instance can be created on top of any network interface,
1094 The Parallel Redundancy Protocol (PRP) is a network redundancy protocol which
1102 health of the network and for discovery of other nodes.
1105 instantiates a virtual, stackable network interface with two member ports.
1108 of RedBox and QuadBox are not implemented (therefore, bridging a hsr network