В Fri, 04.10.2002, в 19:39, Vincent Jardin написал:
> It looks like your BSD kernel is not compiled with the IPv6 support.
Yes, I know
> Le Vendredi 4 Octobre 2002 15:51, "Vladimir B. " Grebenschikov a écrit :
> > Hi
> >
> > I have tried to install fresh zebra (from ports) on 4.7-RC2
> >
> > hav
> -Original Message-
> From: Steve Francis [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, October 06, 2002 3:13 AM
> To: [EMAIL PROTECTED]
> Subject: Help with net.inet.ip.intr_queue_maxlen
>
>
> Can someone help me with net.inet.ip.intr_queue_maxlen tuning?
>
> Firstly, its the "size of
Is anyone using the intel dual gigabit 82546EB? Does it appear as two
separate em devices, eg em0 and em1?
http://www.intel.com/network/connectivity/products/pro1000mt_dual_server_ada
pter.htm
is a card that has it, also some of the newer supermicro motherboards
(and probably others) incorporate
Is there a write-up anywhere about what variables are tuneable, where to
look to see if they need tuning and what the downsides/ramifications are?
I already discovered kern.ipc.maxsockbuf needs to be raised to accommodate
raising the various send and recv spaces. =)
Greets,
DocWilco
Don Bowman wrote:
> Is anyone using the intel dual gigabit 82546EB? Does it appear as two
> separate em devices, eg em0 and em1?
Yup:
em0: port
0x1000-0x103f
em0: Speed:100 Mbps Duplex:Full
em1: port
0x1040-0x107f
em1: Speed:N/A Duplex:N/A
--
Dean C. Strik Eindhoven Universit
÷ Fri, 04.10.2002, × 20:55, Maxim Sobolev ÎÁÐÉÓÁÌ:
> Closer look at zebra's code revealed that my initial guess was
> entirely correct. The problem is that it doesn't bother to zero out
> ifreq structure allocated on stack, which leads to this misbehaviour.
>
> Attached patch should fix the probl
On Sat, Oct 05, 2002 at 05:12:50PM -0700, Steve Francis wrote:
...
> So does that mean after the NIC has received the packet, the interupt
> from the NIC has been processed and the packet retrieved from the NIC,
> then the packet is placed in this queue, before the IP stack looks at it?
yes, unle
On Sun, 6 Oct 2002, Luigi Rizzo wrote:
> large queues to build up in other drivers. E.g. the "xl"
> driver was recently reported to take a long time every second to
> read some info (statistics ?) from the NIC; at 8kpps, 10ms
> is roughly 80 packets, which would easily explain the drops you
> ar
Hi,
I am trying to learn about Netgraph. I have set up
a -CURRENT system for testing. I am reading the tutorial at:
http://www.daemonnews.org/23/netgraph.html
According to this tutorial:
"if your kernel was compiled with options NETGRAPH and you have an Ethernet
interface fxp0, this comm
you also need the ng_eter option..
you can probably get it by:
kldload ng_ether
On Sun, 6 Oct 2002, Craig Rodrigues wrote:
> Hi,
>
> I am trying to learn about Netgraph. I have set up
> a -CURRENT system for testing. I am reading the tutorial at:
> http://www.daemonnews.org/23/netgraph.
On Sun, Oct 06, 2002 at 06:45:59PM -0700, Julian Elischer wrote:
> you also need the ng_eter option..
> you can probably get it by:
> kldload ng_ether
Ah, OK, if I did kldload ng_ether and then did
nghook -a fxp0: divert
it then worked.
This wasn't clear from the daemonnews.org tutorial.
Than
On Sun, 6 Oct 2002, Mike Silbersack wrote:
> But yes, the MII poll was taking 10ms every second until I recently
> committed Harti Brandt's changes to -current. Now it "only" takes 1ms,
> which is still too long, but hard to reduce further. The MFC will have to
> wait until after 4.7-release is
http://www.freebsd.org/~sam/mtag.patch
has changes to -current to replace the "aux mbuf" with a more general
mechanism borrowed from openbsd. Rather than dangling mbuf's off a packet
when auxiliary information needs to be associated with a packet a list of
variable-size struct m_tag's are kept.
On Sun, 6 Oct 2002, Sam Leffler wrote:
> http://www.freebsd.org/~sam/mtag.patch
>
> has changes to -current to replace the "aux mbuf" with a more general
> mechanism borrowed from openbsd. Rather than dangling mbuf's off a packet
> when auxiliary information needs to be associated with a packet
> 1. Is ordering important or is an SLIST sufficient for all cases?
Order is not important.
> 2. Is it possible to attach the aux argument to the mbuf chain instead of
> adding it as a new parameter to ip_output?
>
The "aux argument" _was_ originally attached to the mbuf chain. The change
to a
Sam Leffler wrote:
> > 1. Is ordering important or is an SLIST sufficient for all cases?
>
> Order is not important.
Hm. I don't know if this is actually correct. I think if it went
LIFO, you might not be very happy. I think it depends on what it's
used for.
> > 2. Is it possible to attach
This is not a techincal comment but more
a project question..
What is the relationship between these changes and the KAME
code? In particular, are they goign to take these
changes back into Kame? Can you outline the compatibility
issues, both with KAME, and with NetBSD and OpenBSD, as I know yo
17 matches
Mail list logo
