netdev - [0/2] macvlan: Handle broadcasts in work queue

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

Message-ID: <20140407075347.GA26461@gondor.apana.org.au>
Date:	Mon, 7 Apr 2014 15:53:47 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: [0/2] macvlan: Handle broadcasts in work queue

Hi:

These two patches fix a problem where the macvlan driver tries
to do too much work in netif_receive_skb.  In particular, for
broadcasts it'll send one skb to each macvlan interface all
within a single netif_receive_skb call.  This is way too much
for netif_rx to handle once the number of macvlans exceeds a
certain level (low thousands).  Even if netif_rx could handle
it, doing this amount of work in a single netif_receive_skb
call seriously skews the balance of the network stack.

These patches fix this by moving broadcasts to process context
so that the scheduler can deal with the fairness issue.  The
immediate problem of the netif_rx limit is handled by using
netif_rx_ni.

Similar issues exist elsewhere in our stack regarding broadcasts,
e.g., the bridge driver.  Luckily, with the bridge driver at
least we happen to have a limit of 256 ports per bridge.  Still,
doing 256 actions in one netif_receive_skb is less than ideal.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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