On Fri, Jun 11, 2021 at 04:27:32PM +0300, Grygorii Strashko wrote: [...]
--- a/drivers/net/ethernet/ti/cpsw_new.c +++ b/drivers/net/ethernet/ti/cpsw_new.c @@ -918,14 +918,17 @@ static netdev_tx_t cpsw_ndo_start_xmit(struct sk_buff *skb, struct cpts *cpts = cpsw->cpts; struct netdev_queue *txq; struct cpdma_chan *txch;
- unsigned int len; int ret, q_idx;
- if (skb_padto(skb, CPSW_MIN_PACKET_SIZE)) {
- if (skb_padto(skb, priv->tx_packet_min)) { cpsw_err(priv, tx_err, "packet pad failed\n"); ndev->stats.tx_dropped++; return NET_XMIT_DROP; }
- len = skb->len < priv->tx_packet_min ? priv->tx_packet_min : skb->len;
- if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP && priv->tx_ts_enabled && cpts_can_timestamp(cpts, skb)) skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
@@ -937,7 +940,7 @@ static netdev_tx_t cpsw_ndo_start_xmit(struct sk_buff *skb, txch = cpsw->txv[q_idx].ch; txq = netdev_get_tx_queue(ndev, q_idx); skb_tx_timestamp(skb);
- ret = cpdma_chan_submit(txch, skb, skb->data, skb->len,
- ret = cpdma_chan_submit(txch, skb, skb->data, len, priv->emac_port); if (unlikely(ret != 0)) { cpsw_err(priv, tx_err, "desc submit failed\n");
This change is odd because cpdma_chan_submit() already pads the DMA length.
Would it not make more sense to update cpdma_params::min_packet_size instead of adding a second minimum?
[...]
@@ -1686,6 +1690,7 @@ static int cpsw_dl_switch_mode_set(struct devlink *dl, u32 id, priv = netdev_priv(sl_ndev); slave->port_vlan = vlan;
priv->tx_packet_min = CPSW_MIN_PACKET_SIZE_VLAN; if (netif_running(sl_ndev)) cpsw_port_add_switch_def_ale_entries(priv, slave);@@ -1714,6 +1719,7 @@ static int cpsw_dl_switch_mode_set(struct devlink *dl, u32 id, priv = netdev_priv(slave->ndev); slave->port_vlan = slave->data->dual_emac_res_vlan;
priv->tx_packet_min = CPSW_MIN_PACKET_SIZE; cpsw_port_add_dual_emac_def_ale_entries(priv, slave);
[...]
What happens if this races with the TX path? Should there be a netif_tx_lock() / netif_tx_unlock() around this change?
Ben.