netdev - Despite of traffic control on host netdevice, is it worth to impose a limit control on qemu emulated net device?

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>] [day] [month] [year] [list]

Date:	Thu, 5 Apr 2012 10:30:33 +0800
From:	Liu ping fan <kernelfans@...il.com>
To:	qemu-devel@...gnu.org, netdev@...r.kernel.org
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Stefan Hajnoczi <stefanha@...il.com>,
	Anthony Liguori <anthony@...emonkey.ws>,
	linux-kernel@...r.kernel.org
Subject: Despite of traffic control on host netdevice, is it worth to impose a
 limit control on qemu emulated net device?

Hi,

As we know, in order to control the guest OS's TX rate limit, we can
apply rate limit on ingress Qdisc of host's tap device.
But I think skb will be dropped on host's tap ingress Qdisc, which
means that for those protocol lacking of congestion control such as
UDP, it will cost a lot of meaningless time to produce dropped packet
.

What about introducing rate limit on qemu's emulated net device?  I
think guest's UDP transaction will be  blocked at wait_for_wmem.

Thanks and regards,
pingfan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html