On Fri, Mar 03, 2006 at 10:10:40AM +0200, S.I wrote:
> Thanks for your reply i know this info from google.
> The situation is I have a router with many vlans and i want to change
> the ipprecedence for some networks as I don't want to check hosts in static
> table because
&g
Thanks for your reply i know this info from google.
The situation is I have a router with many vlans and i want to change
the ipprecedence for some networks as I don't want to check hosts in static
table because
this check is too slowly for ingoing ( 4p/s ):) for other routers b
[Redirected to -questions from -net.]
From: S.I
>
> How Can I set ipprecedence flag on FreeBSD?
Precendence bits are part of the ip_tos bits in FreeBSD inet sockets. The
ip(4) man page gives an example of using setsockopt(2) to set the ToS bits.
See src/sys/netinet/ip.h (v1.29) lines 76
How Can I set ipprecedence flag on FreeBSD?
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Mon, Jul 07, 2003 at 09:12:47PM +0100, Bruce M Simpson wrote:
...
> With the increased interest in VoIP and similar these days, perhaps hardware
> DS/QoS support of this nature is something the project should explore?
the usual problem here is that if you want your mechanisms to be
useful, you
On Sat, Jul 05, 2003 at 12:33:32PM -0700, Luigi Rizzo wrote:
> permit. Certain hardware even has multiple, prioritized
> transmit rings, but there is no support for them in our
> drivers (basically we don't have an API for that).
One example which immediately springs to mind is the RTL8139C+ which
If, in your description, RWRs already do prioritization, that
is all what matters, them being the bottleneck nodes.
I still believe your problem is elsewhere.
Maybe the RWR's do not do prioritization despite their claims.
Perhaps your link is just way too overloaded and you need
to shape other t
> > > How could the scheduler decide when to drain the queue ?
> > It should move packets from zero-bw WFQ pipe the interface FIFO
> > as soon as possible but should consider weights
> with infinite bandwidth (that is what 'bw 0' means),
> "as soon as possible" means immediately, so you will
> neve
Eugene Grosbein wrote:
Luigi Rizzo wrote:
How could the scheduler decide when to drain the queue ?
It should move packets from zero-bw WFQ pipe the interface FIFO
as soon as possible but should consider weights
(100 packets from one queue then 1 from another and so on).
That would no
On Sun, Jul 06, 2003 at 05:41:58PM +0800, Eugene Grosbein wrote:
> Luigi Rizzo wrote:
>
> > > > zero-bw pipes are only useful to add delay or to count
> > > > traffic (e.g. using masks), but will never cause queues
> > > > to build up and so won't help in your case.
> > >
> > > That's sad; it woul
Luigi Rizzo wrote:
> > > zero-bw pipes are only useful to add delay or to count
> > > traffic (e.g. using masks), but will never cause queues
> > > to build up and so won't help in your case.
> >
> > That's sad; it would be nice if dummynet would create queues for zero-bw
> > pipes and perform deq
On Sun, Jul 06, 2003 at 03:46:21PM +0800, Eugene Grosbein wrote:
...
> > zero-bw pipes are only useful to add delay or to count
> > traffic (e.g. using masks), but will never cause queues
> > to build up and so won't help in your case.
>
> That's sad; it would be nice if dummynet would create queu
Luigi Rizzo wrote:
> > Thank you for detailed explanation. I hope that dummynet's WFQ
> > would be sufficient but not sure: will it correctly process
> > weights whith zero-bandwidth pipe?
>
> zero-bw pipes are only useful to add delay or to count
> traffic (e.g. using masks), but will never cau
On Sun, Jul 06, 2003 at 10:49:29AM +0800, Eugene Grosbein wrote:
> Luigi Rizzo wrote:
>
> > Bottom line -- the whole architecture has been designed with
> > FIFO in mind, and implementing any different queueing policy
> > will involve some significant rewriting of the device drivers,
> > plus, pot
Luigi Rizzo wrote:
> Bottom line -- the whole architecture has been designed with
> FIFO in mind, and implementing any different queueing policy
> will involve some significant rewriting of the device drivers,
> plus, potentially, some significant performance loss.
Thank you for detailed explanat
sorry for the late reply...
[thread about prioritizing packet at the bottleneck interface]
On Thu, Jul 03, 2003 at 09:27:22AM +0800, Eugene Grosbein wrote:
...
> In addition to dummynet WFQ queue there is interface FIFO queue.
unfortunately, there are actually two queues -- one is
struct ifnet:s
Michael Sierchio wrote:
>
> Eugene Grosbein wrote:
>
> > Then, if prioritized packed arrives when FIFO is not empty,
> > it will not be allowed to go out before packets without ipprecedence
> > that are already in FIFO. That's bad.
>
> That's no
Eugene Grosbein wrote:
Then, if prioritized packed arrives when FIFO is not empty,
it will not be allowed to go out before packets without ipprecedence
that are already in FIFO. That's bad.
That's not quite right. The prioritized packet will presumably be
handled by a different (dummy
On Wed, Jul 02, 2003 at 09:18:48AM -0700, Luigi Rizzo wrote:
> > > It seems to me you could use dummynet/ipfw2 to provide a
> > > stronge PREFERENCE for packets w/non-zero precedence --
> ...
> > And what bandwidth of pipe should I use?
> > Note that I do not need traffic shaping,
> > I need to re
s with ipprecedence, they probably come into
interface's FIFOs first and will go out first. That's good,
but that is not guaranteed.
Then, if prioritized packed arrives when FIFO is not empty,
it will not be allowed to go out before packets without ipprecedence
that are already in FIFO. Tha
On Wed, Jul 02, 2003 at 11:54:42PM +0800, Eugene Grosbein wrote:
> > It seems to me you could use dummynet/ipfw2 to provide a
> > stronge PREFERENCE for packets w/non-zero precedence --
...
> And what bandwidth of pipe should I use?
> Note that I do not need traffic shaping,
> I need to rearrange q
> It seems to me you could use dummynet/ipfw2 to provide a
> stronge PREFERENCE for packets w/non-zero precedence --
> the fairness aspect of dummynet queues works against your
> stated aim, but probabilistically you could pass all
> such packets ahead of others. The fairness guarantee
> means th
Eugene Grosbein wrote:
Suppose, we have a router running FreeBSD 4.8-STABLE.
Some of transit IP-packets have non-zero IP Precedence.
Is it possible to set up the router to rearrange interface queues
so that such packets are sent first?
It seems to me you could use dummynet/ipfw2 to provide a
stron
Hi!
Suppose, we have a router running FreeBSD 4.8-STABLE.
Some of transit IP-packets have non-zero IP Precedence.
Is it possible to set up the router to rearrange interface queues
so that such packets are sent first?
Eugene
___
[EMAIL PROTECTED] mailing
rsion is
.Ar ver .
+.It Cm ipprecedence Ar precedence
+Match if the numeric value of IP datagram's precedence is equal to
+.Ar precedence .
.It Cm iptos Ar spec
Match if the IP header contains the comma separated list of
service types specified in
diff -u --exclude=*orig /usr/src/sbin/i
25 matches
Mail list logo
