Re: [PATCH net-next] net: ti: fix return type of ndo_start_xmit function

[Grygorii Strashko]

Hi All,

On 09/26/2018 12:17 PM, David Miller wrote:
> From: YueHaibing <yuehaibing@xxxxxxxxxx>
> Date: Wed, 26 Sep 2018 17:09:51 +0800
> 
>> @@ -1290,7 +1291,7 @@ static int netcp_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>>   			dev_warn(netcp->ndev_dev, "padding failed (%d), packet dropped\n",
>>   				 ret);
>>   			tx_stats->tx_dropped++;
>> -			return ret;
>> +			return NETDEV_TX_BUSY;
>>   		}
>>   		skb->len = NETCP_MIN_PACKET_SIZE;
>>   	}
>> @@ -1298,7 +1299,6 @@ static int netcp_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>>   	desc = netcp_tx_map_skb(skb, netcp);
>>   	if (unlikely(!desc)) {
>>   		netif_stop_subqueue(ndev, subqueue);
>> -		ret = -ENOBUFS;
>>   		goto drop;
>>   	}
>>   
>> @@ -1319,7 +1319,7 @@ static int netcp_ndo_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>>   	if (desc)
>>   		netcp_free_tx_desc_chain(netcp, desc, sizeof(*desc));
>>   	dev_kfree_skb(skb);
>> -	return ret;
>> +	return NETDEV_TX_BUSY;
>>   }
> 
> These conversions are not correct.
> 
> If the driver frees the SKB you must not return NETDEV_TX_BUSY.
> 
> NETDEV_TX_BUSY tells the caller that the driver could not process the
> packet and that it should reqeueu up the SKB and try again later when
> there is more TX queue room.
> 

Sry, but I still do not understand the reason for these changes (as I asked already [1])
May be there are some patches on the fly or long term decisions were made in this area.

According to the code include/linux/netdevice.h the .ndo_start_xmit() can return 3 type of values
1) enum netdev_tx, expected to be used by regular netdev drivers, but
2) "error while transmitting (rc < 0)" is also acceptable values
3) NET_XMIT_SUCCESS/DROP/CN (qdisc ->enqueue() return codes) for Virtual network devices 

So, are there plans to move NET_XMIT_XXX in enum? 
or any patches to change include/linux/netdevice.h "Transmit return codes:" section?

Not sure, that blindly following coccinelle recommendations is a good
choice in this particular case.

[1] https://lkml.org/lkml/2018/9/20/881

-- 
regards,
-grygorii