: Cleanup pfifo_fast qdisc and remove unnecessary code

Removes the skb trimming code which is not needed since we never touch the skb upon failure. Removes unnecessary initializers, and simplifies the code a bit.

Index: net-2.6.13/net/sched/sch_generic.c
===================================================================
@@ -311,6 +311,8 @@ static const u8 prio2band[TC_PRIO_MAX+1]
    generic prio+fifo combination.
  */
 
+#define PFIFO_FAST_BANDS 3
+
 static inline struct sk_buff_head *prio2list(struct sk_buff *skb,
 					     struct Qdisc *qdisc)
 {

@@ -318,8 +320,7 @@ static inline struct sk_buff_head *prio2
 	return list + prio2band[skb->priority & TC_PRIO_MAX];
 }
 
-static int
-pfifo_fast_enqueue(struct sk_buff *skb, struct Qdisc* qdisc)
+static int pfifo_fast_enqueue(struct sk_buff *skb, struct Qdisc* qdisc)
 {
 	struct sk_buff_head *list = prio2list(skb, qdisc);
 

@@ -331,36 +332,34 @@ pfifo_fast_enqueue(struct sk_buff *skb, 
 	return qdisc_drop(skb, qdisc);
 }
 
-static struct sk_buff *
-pfifo_fast_dequeue(struct Qdisc* qdisc)
+static struct sk_buff *pfifo_fast_dequeue(struct Qdisc* qdisc)
 {
 	int prio;
 	struct sk_buff_head *list = qdisc_priv(qdisc);
 
-	for (prio = 0; prio < 3; prio++, list++) {
+	for (prio = 0; prio < PFIFO_FAST_BANDS; prio++, list++) {
 		struct sk_buff *skb = __qdisc_dequeue_head(qdisc, list);
 		if (skb) {
 			qdisc->q.qlen--;
 			return skb;
 		}
 	}
+
 	return NULL;
 }
 
-static int
-pfifo_fast_requeue(struct sk_buff *skb, struct Qdisc* qdisc)
+static int pfifo_fast_requeue(struct sk_buff *skb, struct Qdisc* qdisc)
 {
 	qdisc->q.qlen++;
 	return __qdisc_requeue(skb, qdisc, prio2list(skb, qdisc));
 }
 
-static void
-pfifo_fast_reset(struct Qdisc* qdisc)
+static void pfifo_fast_reset(struct Qdisc* qdisc)
 {
 	int prio;
 	struct sk_buff_head *list = qdisc_priv(qdisc);
 
-	for (prio=0; prio < 3; prio++)
+	for (prio = 0; prio < PFIFO_FAST_BANDS; prio++)
 		__qdisc_reset_queue(qdisc, list + prio);
 
 	qdisc->qstats.backlog = 0;

@@ -369,35 +368,30 @@ pfifo_fast_reset(struct Qdisc* qdisc)
 
 static int pfifo_fast_dump(struct Qdisc *qdisc, struct sk_buff *skb)
 {
-	unsigned char	 *b = skb->tail;
-	struct tc_prio_qopt opt;
+	struct tc_prio_qopt opt = { .bands = PFIFO_FAST_BANDS };
 
-	opt.bands = 3; 
 	memcpy(&opt.priomap, prio2band, TC_PRIO_MAX+1);
 	RTA_PUT(skb, TCA_OPTIONS, sizeof(opt), &opt);
 	return skb->len;
 
 rtattr_failure:
-	skb_trim(skb, b - skb->data);
 	return -1;
 }
 
 static int pfifo_fast_init(struct Qdisc *qdisc, struct rtattr *opt)
 {
-	int i;
+	int prio;
 	struct sk_buff_head *list = qdisc_priv(qdisc);
 
-	for (i=0; i<3; i++)
-		skb_queue_head_init(list+i);
+	for (prio = 0; prio < PFIFO_FAST_BANDS; prio++)
+		skb_queue_head_init(list + prio);
 
 	return 0;
 }
 
 static struct Qdisc_ops pfifo_fast_ops = {
-	.next		=	NULL,
-	.cl_ops		=	NULL,
 	.id		=	"pfifo_fast",
-	.priv_size	=	3 * sizeof(struct sk_buff_head),
+	.priv_size	=	PFIFO_FAST_BANDS * sizeof(struct sk_buff_head),
 	.enqueue	=	pfifo_fast_enqueue,
 	.dequeue	=	pfifo_fast_dequeue,
 	.requeue	=	pfifo_fast_requeue,

Is netdev not fed regularely so it started munching messages again? I've not received the introduction message and patches 1-5 back only 6-7 which have been sitting in the queue due to refused connections for a while. Am I the only one having troubles?

From: Thomas Graf <[email protected]>
Date: Tue, 7 Jun 2005 23:36:21 +0200

This is exactly what I saw as well.

I did get all of your postings because you sent them with me on the CC: list, but netdev only sent out 6 and 7 to me just as you observed.

This has become a regular occurance, it may be time to finally move this thing over to vger.kernel.org. Thoughts?

* David S. Miller <[email protected]> 2005-06-07 14:42

I tried to resend, the message were accepted by oss.sgi.com but none of them came back. Maybe dropped due to duplicated message ids though.

I have no personal objections, would be valuable to take over the archives though.

I thought netdev just picks on me ;-> My stoopid ISP as well as oss.sgi.com have some "clever" (read: questionable) ways of delivering email which violates end to end semantics of SMTP. I too noticed some emails were swallowed in the last 1-2 days. I know from past experience in fact they will never be seen again;-> Or someone, who doesnt look at the headers, will flame me for repeating what has already been discussed and agreed on (has happened to me at least 5 times on netdev ;->).

It's quiet ironic when packets delivered over TCP dont make it to the remote end, even when the app tries to help in reliable delivery;->

CCing El-sido Bacchus.

cheers,
jamal

Turns out that Thomas Graf's Email was intercepted by the spam filter, so I've tweaked the filter setup a bit - probably at the price of sacrificing some of the filter's effectivity.

It unfortunately has become totally impractical to walk through the hundreds of moderator emails every day due to the volume, so I need to rely on people to report about such problem to [email protected] or me directly via email or irc.

As for resending messages, due to people doing stupid things such as restoring their mail and news spools oss is keeping a non-expiring list of message IDs. However only non-spam message IDs are being recorded.

Ralf

* Ralf Baechle <[email protected]> 2005-06-08 17:04

Can you tell me why it was filtered? It might be a problem with my patch script which I could fix on my side. How much work would it be to whitelist a few people?

The weird thing is that patches 6-7 which could not be delivered immediately due to connection refused from oss.sgi.com came through fine.

Whitelists tend to be problematic due to the enormous amounts of spam and malware emails that come with forged email addresses.

I'll send you the rules in question and the original spamyness scores they did compute in separate email, it's somewhat bigish.

Whatever it was, it was probably a separate issue from this spamfilter faux-pas. Note there is a firewall in front of oss.sgi.com which will accept the SMTP TCP connection only to drop the connection shortly after if it can't build a connection to the "real" oss. So if you only get a connection refused message when telneting to oss it really means the firewall had some issues. Unfortunately I don't have any control over it, if I had I'd replace it with a nice patchcable ;-)

Ralf

* Ralf Baechle <[email protected]> 2005-06-08 18:28

I'm not worried about a refused connections once in a while, I'm worried about that exactly those two messages that have been sitting in _my_ queue due to a refused connection to oss.sgi.com have been succesfully delivered and the others have not.

Is there a messages/time limit somwhere? If so what's the limit? I tried with 30 seconds delay between each patch but that didn't help.

From: Thomas Graf <[email protected]>
Date: Wed, 8 Jun 2005 22:00:48 +0200

I see the delay due to SGI's firewall when I send postings out too, and it's very annoying.

The fact that I can send an email faster to Herbert Xu in Australia (several thousand miles away) than oss.sgi.com (which is a short drive away) would be an amusing anecdote if it didn't negatively impact my work.

I think it's time to move this list to a more reliable and efficient place.

Ralf, thanks for all of your effort and time maintaining oss.sgi.com for our stay as guests via the netdev list.

I've created [email protected], and folks can start to join up there. If someone knows the appropriate archive maintainers to contact (marc.theaimsgroup.com et al.) please let them know about this transition. It would be much apprecited.

On Wed, 08 Jun 2005 13:10:44 -0700 (PDT) David S. Miller wrote:

| Ralf, thanks for all of your effort and time maintaining | oss.sgi.com for our stay as guests via the netdev list.

Thanks from here also.

| I've created [email protected], and folks can start
| to join up there.  If someone knows the appropriate
| archive maintainers to contact (marc.theaimsgroup.com
| et al.) please let them know about this transition.  It
| would be much apprecited.

I've done that before and now.
(made the request, not acked by Hank yet)

---
~Randy

From: Nivedita Singhvi <[email protected]>
Date: Wed, 08 Jun 2005 15:42:14 -0700

It should not be used any longer as of today. I'm changing oss.sgi.com to vger.kernel.org in every posting I reply to.

On Wed, Jun 08, 2005 at 01:10:44PM -0700, David S. Miller wrote:

Akpm: Patch with netdev address change below.

Correction on that, while the bloody PIX is still installed, it's SMTP proxy is disabled.

Performance is partially explained by running sendsnail - against my resistance.

How about I simply give you the old subscriber list and turn netdev@oss into a forward or autoresponder?

There are archives on oss itself at http://oss.sgi.com/archives/netdev as well.

Ralf

 Documentation/networking/vortex.txt |    2 -
 MAINTAINERS                         |   48 ++++++++++++++++++------------------
 drivers/net/r8169.c                 |    2 -
 net/sched/act_api.c                 |    2 -
 4 files changed, 27 insertions(+), 27 deletions(-)

Index: linux-cvs/drivers/net/r8169.c
===================================================================
@@ -415,7 +415,7 @@
 	struct work_struct task;
 };
 
-MODULE_AUTHOR("Realtek and the Linux r8169 crew <[email protected]>");
+MODULE_AUTHOR("Realtek and the Linux r8169 crew <[email protected]>");
 MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver");
 module_param_array(media, int, &num_media, 0);
 module_param(rx_copybreak, int, 0);

Index: linux-cvs/Documentation/networking/vortex.txt
===================================================================
@@ -12,7 +12,7 @@
 Please report problems to one or more of:
 
   Andrew Morton <[email protected]>
-  Netdev mailing list <[email protected]>
+  Netdev mailing list <[email protected]>
   Linux kernel mailing list <[email protected]>
 
 Please note the 'Reporting and Diagnosing Problems' section at the end

Index: linux-cvs/net/sched/act_api.c
===================================================================
@@ -881,7 +881,7 @@
 		link_p[RTM_GETACTION-RTM_BASE].dumpit = tc_dump_action;
 	}
 
-	printk("TC classifier action (bugs to [email protected] cc "
+	printk("TC classifier action (bugs to [email protected] cc "
 	       "[email protected])\n");
 	return 0;
 }

Change the address of netdev in 2.4 also.

 Documentation/networking/vortex.txt |    2 +-
 MAINTAINERS                         |   10 +++++-----
 2 files changed, 6 insertions(+), 6 deletions(-)

Index: linux-cvs-2.4/Documentation/networking/vortex.txt
===================================================================
@@ -12,7 +12,7 @@
 Please report problems to one or more of:
 
   Andrew Morton <[email protected]>
-  Netdev mailing list <[email protected]>
+  Netdev mailing list <[email protected]>
   Linux kernel mailing list <[email protected]>
 
 Please note the 'Reporting and Diagnosing Problems' section at the end

Index: linux-cvs-2.4/MAINTAINERS
===================================================================
@@ -116,7 +116,7 @@
 8169 10/100/1000 GIGABIT ETHERNET DRIVER
 P:	Francois Romieu
 M:	[email protected]
-L:	[email protected]
+L:	[email protected]
 S:	Maintained
 
 8250/16?50 (AND CLONE UARTS) SERIAL DRIVER

@@ -1186,7 +1186,7 @@
 P:	Manish Lachwani
 M:	[email protected]
 L:	[email protected]
-L:	[email protected]
+L:	[email protected]
 S:	Supported
 
 MARVELL YUKON / SYSKONNECT DRIVER

@@ -1315,7 +1315,7 @@
 
 NETWORKING [GENERAL]
 P:	Networking Team
-M:	[email protected]
+M:	[email protected]
 L:	[email protected]
 S:	Maintained
 

@@ -1332,7 +1332,7 @@
 M:	[email protected]
 P:	Patrick McHardy
 M:	[email protected]
-L:	[email protected]
+L:	[email protected]
 S:	Maintained
 
 NFS CLIENT

@@ -1529,7 +1529,7 @@
 PRISM54 WIRELESS DRIVER
 P:	Prism54 Development Team
 M:	[email protected]
-L:	[email protected]
+L:	[email protected]
 W:	http://prism54.org
 S:	Maintained
 

Ralf,

Since DaveM moved the list can you probably put a forwarding to [email protected] ?
We should also probably announce the change of address in the usual suspect lists.

BTW, I too would like to join the masses of people who are thankful to all your great efforts.
You sir are a hacker and a gentleman.

cheers,
jamal