linux-kernel - Re: net-sched: When TX over-limit happens on netdev, what does kernel do?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 01 Apr 2012 10:44:39 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Liu ping fan <kernelfans@...il.com>
Cc:	linux-net@...r.kernel.org, Jamal Hadi Salim <hadi@...erus.ca>,
	linux-kernel@...r.kernel.org
Subject: Re: net-sched: When TX over-limit happens on netdev, what does
 kernel do?

On Sun, 2012-04-01 at 16:27 +0800, Liu ping fan wrote:
> Hi,
> 
> Could anybody tell me when TX over-limit happens on netdev, what does kernel do?
> Is skb buffered in Qdisc->q and the sending process keeps running?

Are you referring to the NETDEV_TX_BUSY return code processing ?

> Or we block the sending process and make it scheduled?
> 

We never block the sender process in qdisc layer.

Only upper protocol layers can eventually block if too many packets are
in flight on the socket.

> Found some code in net/sched/sch_cbq.c
> cbq_dequeue(struct Qdisc *sch) --> qdisc_watchdog_schedule(),  so I
> guess the skb is buffered in Qdisc, but what about sending process?

sender queued its packet and doesnt care if the packet is sent or not.

Only problem is when qdisc limit (number of packets in queue) is hit,
then we can return an error to sender (packet dropped or congestion
notification)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/