[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <FB112703C4930F4ABEBB5B763F96491139379DC7@MAILSERV2A.lorien.fkie.fgan.de>
Date: Tue, 3 Jul 2012 07:29:35 +0000
From: "Erdt, Ralph" <ralph.erdt@...e.fraunhofer.de>
To: Eric Dumazet <eric.dumazet@...il.com>,
Nicolas de Pesloüan
<nicolas.2p.debian@...il.com>
CC: Rick Jones <rick.jones2@...com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: AW: AW: AW: RFC: replace packets already in queue
> > If I were you, I would use a tun/tap interface and manage a private
> > packet queue in userspace. This way, you wouldn't have to manage the
> overhead of porting your kernel code to every new kernel versions.
> >
>
> This seems a good idea.
>
> Then you can do other coalescing stuff, like TCP ACK that could be
> aggregated to single ACK as well.
Thanks for the idea. But this is option when just doing the replace thing.
But the charm of the qdisc solution is the complete integration to TC. It's complete compatible to the other options, so that you can create a bigger TC rule set. And creating the rules is a standard operation for the administrators - they know TC.
In terms of the other coalescing stuff (we didn't use TCP, because it's not possible) - it's already done in the device "driver" I mentioned. Yes, we can extend the "driver", but the qdisc solution has the benefit that there is a clear separation.
Nevertheless we will discuss the idea internally. Maybe the group got another idea based on this.
--
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