Properties of the Netif_f_lltx

When Bond is initialized, we can see the following properties:

/* don ' t acquire Bond device ' s netif_tx_lock when transmitting */Bond_dev->features |= netif_f_lltx; You can also see this property when the LO port is set:

Static voidLoopback_setup (structNet_device *Dev) {Dev->MTU = -*1024x768; Dev->hard_header_len = Eth_hlen;/* -*/Dev->addr_len = Eth_alen;/*6*/Dev->type = Arphrd_loopback;/*0x0001*/Dev->flags =Iff_loopback; Dev->priv_flags |= Iff_live_addr_change |Iff_no_queue;    NETIF_KEEP_DST (Dev); Dev->hw_features =Netif_f_gso_software; Dev->features = Netif_f_sg |netif_f_fraglist|Netif_f_gso_software|Netif_f_hw_csum|Netif_f_rxcsum|NETIF_F_SCTP_CRC|NETIF_F_HIGHDMA|Netif_f_lltx|netif_f_netns_local|netif_f_vlan_challenged|Netif_f_loopback; Dev->ethtool_ops = &Loopback_ethtool_ops; Dev->header_ops = &Eth_header_ops; Dev->netdev_ops = &Loopback_ops; Dev->destructor =Loopback_dev_free;}

The Netif_f_lltx property represents that we do not need to acquire a lock when we contract.

For non-virtual devices, such as the actual network card, this property is generally not set, that is, the need to obtain a TX lock.

However, it is also commented that the following driver is best not to use this feature:

* LLTX driver (deprecated forHardware Drivers) Netif_f_lltx should beSet inchDrivers that implement their own lockinginchtransmit path or Don't need locking at all (e.g. software tunnels).In Ndo_start_xmit, it isRecommended to use a try_lock andreturnnetdev_tx_locked when the spinLockfails. The locking should also properlyprotect against other callbacks (the rules you need to find out). Don't use it for new drivers.

Properties of the Netif_f_lltx