[PATCH net-next] net: dlink: count tx_dropped when dropping skb on link down

[PATCH net-next] net: dlink: count tx_dropped when dropping skb on link down

[Yeounsu Moon]

Increment tx_dropped when dropping the skb due to link down.

Tested-on: D-Link DGE-550T Rev-A3
Signed-off-by: Yeounsu Moon <yyyynoom@gmail.com>
---
 drivers/net/ethernet/dlink/dl2k.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/dlink/dl2k.c b/drivers/net/ethernet/dlink/dl2k.c
index 846d58c769ea..edc6cd64ac56 100644
--- a/drivers/net/ethernet/dlink/dl2k.c
+++ b/drivers/net/ethernet/dlink/dl2k.c
@@ -733,6 +733,7 @@ start_xmit (struct sk_buff *skb, struct net_device *dev)
 	u64 tfc_vlan_tag = 0;
 
 	if (np->link_status == 0) {	/* Link Down */
+		dev->stats.tx_dropped++;
 		dev_kfree_skb_any(skb);
 		return NETDEV_TX_OK;
 	}
-- 
2.52.0

Re: [PATCH net-next] net: dlink: count tx_dropped when dropping skb on link down

[Andrew Lunn]

On Tue, Jan 06, 2026 at 09:23:51PM +0900, Yeounsu Moon wrote:
> Increment tx_dropped when dropping the skb due to link down.
> 
> Tested-on: D-Link DGE-550T Rev-A3
> Signed-off-by: Yeounsu Moon <yyyynoom@gmail.com>
> ---
>  drivers/net/ethernet/dlink/dl2k.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ethernet/dlink/dl2k.c b/drivers/net/ethernet/dlink/dl2k.c
> index 846d58c769ea..edc6cd64ac56 100644
> --- a/drivers/net/ethernet/dlink/dl2k.c
> +++ b/drivers/net/ethernet/dlink/dl2k.c
> @@ -733,6 +733,7 @@ start_xmit (struct sk_buff *skb, struct net_device *dev)
>  	u64 tfc_vlan_tag = 0;
>  
>  	if (np->link_status == 0) {	/* Link Down */
> +		dev->stats.tx_dropped++;

Do you see this being hit very often? It should be that as soon as you
know the link is down, you tell the core, and it will stop calling
start_xmit. If you see this counter being incremented a lot, it
indicates there is a problem somewhere else.

You might want to consider converting this driver to phylink.

	  Andrew

Re: [PATCH net-next] net: dlink: count tx_dropped when dropping skb on link down

[Yeounsu Moon]

On Tue Jan 6, 2026 at 10:44 PM KST, Andrew Lunn wrote:
> On Tue, Jan 06, 2026 at 09:23:51PM +0900, Yeounsu Moon wrote:
>> Increment tx_dropped when dropping the skb due to link down.
>> 
>> Tested-on: D-Link DGE-550T Rev-A3
>> Signed-off-by: Yeounsu Moon <yyyynoom@gmail.com>
>> ---
>>  drivers/net/ethernet/dlink/dl2k.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/drivers/net/ethernet/dlink/dl2k.c b/drivers/net/ethernet/dlink/dl2k.c
>> index 846d58c769ea..edc6cd64ac56 100644
>> --- a/drivers/net/ethernet/dlink/dl2k.c
>> +++ b/drivers/net/ethernet/dlink/dl2k.c
>> @@ -733,6 +733,7 @@ start_xmit (struct sk_buff *skb, struct net_device *dev)
>>  	u64 tfc_vlan_tag = 0;
>>  
>>  	if (np->link_status == 0) {	/* Link Down */
>> +		dev->stats.tx_dropped++;
>
> Do you see this being hit very often? It should be that as soon as you
> know the link is down, you tell the core, and it will stop calling
> start_xmit. If you see this counter being incremented a lot, it
> indicates there is a problem somewhere else.
>
> You might want to consider converting this driver to phylink.
>
> 	  Andrew

Sorry for the late reply. I recently started my first job and have been
a bit busy settling in.

To answer your question: this path is hit extremely rarely. In practice,
I only observed it in rather extreme cases, such as forcibly
disconnecting the physical link (e.g. unplugging the Ethernet cable). I
have not seen it occurring during normal operation.

Given that, dropping the packet in this situation seems reasonable, so I
added a counter to make such cases visible. However, I am not entirely
sure whether this is the right direction, or whether this is just
masking a problem that should be handled elsewhere.

Do you think this should instead be addressed by improving how link-down
is propagted to the core, or would converting this driver to phylink
help avoid or improve this situation?

    Yeounsu

Re: [PATCH net-next] net: dlink: count tx_dropped when dropping skb on link down

[Andrew Lunn]

On Tue, Jan 13, 2026 at 08:30:45PM +0900, Yeounsu Moon wrote:
> On Tue Jan 6, 2026 at 10:44 PM KST, Andrew Lunn wrote:
> > On Tue, Jan 06, 2026 at 09:23:51PM +0900, Yeounsu Moon wrote:
> >> Increment tx_dropped when dropping the skb due to link down.
> >> 
> >> Tested-on: D-Link DGE-550T Rev-A3
> >> Signed-off-by: Yeounsu Moon <yyyynoom@gmail.com>
> >> ---
> >>  drivers/net/ethernet/dlink/dl2k.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >> 
> >> diff --git a/drivers/net/ethernet/dlink/dl2k.c b/drivers/net/ethernet/dlink/dl2k.c
> >> index 846d58c769ea..edc6cd64ac56 100644
> >> --- a/drivers/net/ethernet/dlink/dl2k.c
> >> +++ b/drivers/net/ethernet/dlink/dl2k.c
> >> @@ -733,6 +733,7 @@ start_xmit (struct sk_buff *skb, struct net_device *dev)
> >>  	u64 tfc_vlan_tag = 0;
> >>  
> >>  	if (np->link_status == 0) {	/* Link Down */
> >> +		dev->stats.tx_dropped++;
> >
> > Do you see this being hit very often? It should be that as soon as you
> > know the link is down, you tell the core, and it will stop calling
> > start_xmit. If you see this counter being incremented a lot, it
> > indicates there is a problem somewhere else.
> >
> > You might want to consider converting this driver to phylink.
> >
> > 	  Andrew
> 
> Sorry for the late reply. I recently started my first job and have been
> a bit busy settling in.
> 
> To answer your question: this path is hit extremely rarely. In practice,
> I only observed it in rather extreme cases, such as forcibly
> disconnecting the physical link (e.g. unplugging the Ethernet cable). I
> have not seen it occurring during normal operation.

In that case, i think this is fine. There is a race condition here
between indicating the carrier is down and the network stopping
passing packets, so this can happen, and incrementing the counter is
fine.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

Re: [PATCH net-next] net: dlink: count tx_dropped when dropping skb on link down

[Moon Yeounsu]

On Tue, Jan 6, 2026 at 10:44 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> You might want to consider converting this driver to phylink.
>
>           Andrew
One more note: I’ve started looking into phylink based on your suggestion,
and I appreciate you pointing me to that keyword.

It seems useful not only for this issue, but also for improving
the driver more generally.

Thanks for the pointer.