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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 28 Jun 2007 14:11:11 -0700 From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com> To: "Patrick McHardy" <kaber@...sh.net>, "Jeff Garzik" <jeff@...zik.org> Cc: <davem@...emloft.net>, <netdev@...r.kernel.org>, "Kok, Auke-jan H" <auke-jan.h.kok@...el.com>, <hadi@...erus.ca> Subject: RE: [PATCH 2/3] NET: [CORE] Stack changes to add multiqueue hardware support API > -----Original Message----- > From: Patrick McHardy [mailto:kaber@...sh.net] > Sent: Thursday, June 28, 2007 12:37 PM > To: Jeff Garzik > Cc: Waskiewicz Jr, Peter P; davem@...emloft.net; > netdev@...r.kernel.org; Kok, Auke-jan H; hadi@...erus.ca > Subject: Re: [PATCH 2/3] NET: [CORE] Stack changes to add > multiqueue hardware support API > > Jeff Garzik wrote: > > Patrick McHardy wrote: > > > >> Yes, but there are users that don't go through qdiscs, > like netpoll, > >> Having them check the QDISC_RUNNING bit seems ugly. > > > > > > Is netpoll the only such user? > > I'm not sure, I just remembered that one :) > > Looking at Peter's multiqueue patch, which should include all > hard_start_xmit users (I'm not seeing sch_teql though, > Peter?) the only other one is pktgen. Ugh. That is another netif_queue_stopped() that needs netif_subqueue_stopped(). I can send an updated patch for the core to fix this based from your patches Patrick. > > > netpoll tends to be a special case in every sense of the > word, and I > > wish it was less so :/ > > Indeed. So what do we do about netpoll then wrt netif_(sub)queue_stopped() being removed from qdisc_restart()? The fallout of having netpoll() cause a queue to stop (queue 0 only) is the skb sent will be requeued, since the driver will return NETIF_TX_BUSY if this actually happens. But this is a corner case, and we won't lose packets; we'll just have increased latency on that queue. Should I worry about this or just move forward with the sch_teql.c change and repost the core patch? Thanks, -PJ Waskiewicz - 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
Powered by blists - more mailing lists