Hiten Pandya wrote:
> On Thu, Jun 19, 2003 at 03:17:03PM -0700, John-Mark Gurney wrote:
> > I am running FreeBSD 5.1-R on a sparc64 machine, and am getting warnings
> > about mallocing data w/ a lock aquired.
> >
> > dmesg output:
> > malloc() of "64" with the following non-sleepablelocks held:
> >
Steve Kargl wrote:
> On Wed, Mar 05, 2003 at 12:24:39PM -0800, Terry Lambert wrote:
> > For heaven's sake! *It has only been 3 days* since the code
> > was threatened! What do you expect *in 3 days*!?!
> >
>
> The code has been broken for 7 years. You've
David O'Brien wrote:
> > Here is a single patch vs. 5.x.
> >
> > I believe this makes it actually work.
>^
>huh? This is untested?
Will you accept interoperability between two FreeBSD boxes? A
FreeBSD box and a NetBSD box?
> > Please apply this to the code, even if you are inte
Mark Murray wrote:
> > How long can this remain unfixed before the code is diked out,
> > and the checksum is recalculated fully, instead?
>
> Terry, you sound rather foolish when you argue like this. This
> is semantic tomfoolery and off topic. End of thread.
This is not a argument over mere imp
Mark Murray wrote:
> Terry Lambert writes:
> > Mark Murray wrote:
> > > Will it be runnable (as in tested), rather than a compile-only fix?
> >
> > Is "tested" a requirement fo code to be committed or to have it
> > stay in the tree?
>
> Both.
Mark Murray wrote:
> Only if it kills this _really_ dumb debate. In time, it will no longer
> compile, and then the situation will be the same as just punting to the
> Attic without the "fix".
Only if some idiot breaks the API contract again.
Whatever happened to "you broke it, you fix it"?
Hop
Petri Helenius wrote:
> > seems to me that one useful question is whether the netns code
> > being there non-trivially complicates maintenance and/or
> > reliability of other code, and can i compile or module it out if
> > the bits it occupies really bothers me?
> >
> This is probably the right que
Peter Wemm wrote:
> Terry Lambert wrote:
> > Here are two patches. The first fixes missing pieces in /sys/conf/files
> > and /sys/conf/options, the second fixes all the files that need it in
> > /sys/netns/.
>
> You seem to have posted the wrong patch.
>
> This
Mark Murray wrote:
> Terry Lambert writes:
> > Peter Wemm wrote:
> > > Terry: will you please check your facts? It takes around 30 seconds
> > > to find out that it doesn't even compile.
> >
> > [ ... lots of trivial to fix warnings and errors ... ]
&g
Doug Barton wrote:
> On Wed, 5 Mar 2003, Terry Lambert wrote:
> > If you want to make it about "failure to attract a maintainer", then
> > do that.
>
> Actually several people have made this argument, along with the corollary
> "failure to attract a userbase
Doug Barton wrote:
> On Wed, 5 Mar 2003, Terry Lambert wrote:
> > The code is still useful as a simple implementation, much more
> > easily understood by the student than the current TCP/IP stack,
> > for certain.
>
> And it will still be available. It'll jus
Mark Linimon wrote:
> > On the other hand, there's no compelling reason to dike it out,
> > if it can be made to work.
>
> work == "not just compiled, but QAed against known-working implementations
> and correctly documented".
>
> Have fun. Looking forward to the patches and logs.
Just to be pe
Juli Mallett wrote:
> * De: Terry Lambert <[EMAIL PROTECTED]> [ Data: 2003-03-05 ]
> [ Subjecte: Re: Removal of netns - politically correct version ]
> > On the other hand, there's no compelling reason to dike it out,
> > if it can be made to work. I wo
Bob Bishop wrote:
> Here's a hint:
>
> "The Apollo Domain and XNS networking protocols will no longer be offered
> after Cisco IOS Release 12.2. Information about these protocols will not
> appear in future releases of the Cisco IOS software documentation set."
> http://www.cisco.com/en/US/product
Terry Lambert wrote:
> Peter Wemm wrote:
> > Terry: will you please check your facts? It takes around 30 seconds
> > to find out that it doesn't even compile.
>
> [ ... lots of trivial to fix warnings and errors ... ]
>
> Tell you what, I'll fix these
Peter Wemm wrote:
> Terry Lambert wrote:
> > Is there a compelling reason for removing this working code to
> > the Attic?
>
> Terry: will you please check your facts? It takes around 30 seconds
> to find out that it doesn't even compile.
[ ... lots of trivi
Wilko Bulte wrote:
> On Tue, Mar 04, 2003 at 07:56:27AM -0800, Terry Lambert wrote:
> > Is there a compelling reason for doing this, other than "I
> > want to make some API/locking change, but I don't want to
> > have to keep this code working at the same tim
Mike Barcroft wrote:
> Terry Lambert <[EMAIL PROTECTED]> writes:
> > Tim Robbins wrote:
> > > Is there a compelling reason why I shouldn't remove netns? That is, does
> > > it serve a purpose now that it could not serve if it was moved to the
> > > A
Tim Robbins wrote:
> Is there a compelling reason why I shouldn't remove netns? That is, does
> it serve a purpose now that it could not serve if it was moved to the
> Attic?
Might as well move /sys/i386/conf/GENERIC to the attic while
you are at it. It can serve it's purpose from there, too.
Is
Mike Silbersack wrote:
> On Tue, 18 Feb 2003, Terry Lambert wrote:
> > See:
> >
> > http://www.psc.edu/networking/tcp.html
> >
> > The code is an easy port. The TCP Rate Halving is a much better
> > approach to the same problem. Code for that is a
See:
http://www.psc.edu/networking/tcp.html
The code is an easy port. The TCP Rate Halving is a much better
approach to the same problem. Code for that is also there, and is
also an easy port.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in th
Max Khon wrote:
> are you talking about src/sys/netiso/ code?
> it has been there but was removed about 7 years ago because nobody wanted to
> maintain it. You can take a look at it via cvsweb.
This is substantially incorrect. The code was working fine, until
FreeBSD's routing code was changed ou
Wes Peters wrote:
> On Friday 07 February 2003 01:25, David Gilbert wrote:
> > I believe that someone here recomended Tigon III based cards ... but I
> > was recently looking through 5.0-RELEASE's hardware notes and couldn't
> > find any mention of Tigon III.
>
> The follow-on to the Tigon II is t
Audsin wrote:
> I am Dev, doing my research in Centre for Telecommunications Research,
> King's college London. My research project involves evaluating the
> performance of MIP6 TCP in the presence of fragmentation and without
> fragmentation. I am using Kame MIP6 for Free BSD 4.4 and have configu
John David Duncan wrote:
> There's a load balancing configuration known as direct server return
> (DSR), in which packets pass from the client through the load balancer to
> the server, but then the replies from the server go directly to the client
> (bypassing the load balancer). The way this wor
Thomas Moestl wrote:
> > > [EINVAL] Listen() has been already called on the socket.
> The manpage change does not reflect the change in the patch :)
> It should be:
>
> [EINVAL]The socket is connected.
Oh. That's very different. Never mind. 8-).
-- Terry
To Uns
Martin Blapp wrote:
> Can you commit this ? The fix looks appropriate, but the manpage should
> also be changed to reflect the change.
>
> ERRORS
> Listen() will fail if:
>
> [EBADF]The argument s is not a valid descriptor.
> [ENOTSOCK] The argument s is not a s
Radoslav Vasilev wrote:
> I'm interested in whether the following could be acomplished:
> there's KLD module, installing some new syscalls in the kernel, as well as
> installing new ``struct ipprotosw'' for some protocol or another(let's
> assume IPPROTO_UDP).
> Could we just add some code in the b
"M. Warner Losh" wrote:
> In message: <[EMAIL PROTECTED]>
> Nate Lawson <[EMAIL PROTECTED]> writes:
> : I was looking into some "could sleep messages" and found some bogus
> : locking in the attach routine of many drivers. Several init a mtx in
> : their softc and then lock/unlock it i
randall ehren wrote:
> it's a bit of a work-in-progress, but if anyone is interested in setting up
> freebsd as a bridging ipfilter firewall + pptp vpn server, in rc.diskless2
> mode, along with the option of having a redundant failover machine:
>
> http://isber.ucsb.edu/~randall/firewall/redunda
Note: Cross-post and "Reply-To:" of freebsd-net!
Tony Finch wrote:
> [EMAIL PROTECTED] (Mike Ghunt) wrote:
> > Has anyone hacked the jail code to support more than one ip?
> >Would it be wise to hack at the code to add such a feature?
>
> Probably the best way to address this issue is to incorpo
Luigi Rizzo wrote:
> > > This patch will not make any difference if you have device_polling
> > > enabled, because polling already does this -- queues a small number
> > > of packets (default is max 5 per card) and calls ip_input on them
> > > right away.
> >
> > The problem with this is that it in
Luigi Rizzo wrote:
> Strictly speaking it is not necessary to get rid of the ipintr()
> code, it will just remain unused, so the relevant part of the patch is
> the direct call of ip_input() instead of schednetisr().
>
> This patch will not make any difference if you have device_polling
> enabled,
Probably help if I attach the patch. 8-).
-- Terry
Terry Lambert wrote:
>
> > Well... I have all those stats, but I wasn't wanting to type that
> > much. IIRC, we normally test with 80 byte packets ... they can be UDP
> > or TCP ... we're testing the routing.
> Well... I have all those stats, but I wasn't wanting to type that
> much. IIRC, we normally test with 80 byte packets ... they can be UDP
> or TCP ... we're testing the routing. The box has two interfaces and
> we measure the number of PPS that get to the box on the other side.
>
> Without poll
soheil soheil wrote:
> Dear All
>
> I want to know what is Snoop TCP , and Is it implemented on FreeBSD or Not ?
Snoop TCP is a mechansim for performing impedence matching between
a network with very little loss attached at the border of a network
with much more loss.
It operates as a pseudo-app
Julian Elischer wrote:
> Also look at ng_etf the ethertype filter..
> it is designed to connect to an ether node and filter out packets
> with a particular ethertype. yuo could alter it to examine for a
> particular tcp port number too.
[ ... ]
A more interesting problem is how to hook an address
sepehr sohrabi wrote:
> Hi list
> Anyone has source code for spoofing (in kernel) for all input Tcp/IP packets
> .For any TCP/IP packet recieve it creates an ACK for it .
> someThing like spoofing GW
> CLIENT <-> GW <---> server
> connections are spoofed
Since the SYN bit has to be
Julian Elischer wrote:
> > There is also the m_pullup() issue of the TCP protocol that is
> > being passed IP datagrams which may be frags of TCP packets, in
> > order to get the full TCP header, with options.
>
> The tcp code should handle this anyway.
It should, but it won't. The issue is when
Vincent Jardin wrote:
> I do not think that you need a raw IP netgraph node. Something similar
> already exists. Why not use the ng_ksocket in order to open a raw IP socket
> under your TCP node ?
Because the packet will never get to your protocol processing, unless
you turn of standard TCP altoge
Steve Tremblett wrote:
> A while back someone was fishing for a project to take on and someone
> suggested a complete TCP/IP implementation in netgraph. I found the
> idea interesting and am considering taking a shot at it. My main goal
> in all this is to learn as much as possible and at this po
Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Bruce Evans writes:
> >Ideally, header files wouldn't have any "variable sized structs" or
> >anything else that depends on options. Core headers have to be much
> >more careful about this because including an options header nested
> >wou
Mike Silbersack wrote:
> On Wed, 9 Oct 2002, Christopher Smith wrote:
> > The rule processing can't be done on the other CPU, can it ? Am I right in
> > saying that at this point in time, buying a dual CPU (vs single CPU) machine
> > for firewalling with FreeBSD is just a waste of money ?
>
> Eve
Don Lewis wrote:
> Why not name them? At boot or module load time stuff the name in a
> table and use the table index as the 16 bit ID. Is there any reason the
> ID has to be the same each time the system is booted?
That was my suggestion. I stopped short of calling it XInternAtom()...
-- Ter
Julian Elischer wrote:
> > Why not name them? At boot or module load time stuff the name in a
> > table and use the table index as the 16 bit ID. Is there any reason the
> > ID has to be the same each time the system is booted?
>
> I want to be able to specify an OLD API and the NEW version
> i
Luigi Rizzo wrote:
> i wonder what do we gain by moving to 32 bit m_tag_id -- because there is
> is still no strict guarantee that we have no conflicts
> if people randomly choose "cookies", and also, using the same reasoning
> for allocations one could argue that having the cookie chosen as the n
Julian Elischer wrote:
> > This is insufficient for Alpha and other 64 bit architectures. I
> > think what you are asking for is really a 'void *'.
>
> IT IS NOT A POINTER!
>
> it is a 32 bit unsigned number.
OK, I give up. Why is 2^32 possibilities better than 2^16th
possibilities? You have
Julian Elischer wrote:
> Firstlty, each netgraph module type is ignorant of
> all other types (except in some special cases). Each 'type'
> labels its structures, control messages, and in fact special metadata
> that it keeps on a packet, using a special maginc number. Each 'type'
> of netgraph no
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
soheil h wrote:
> Hi
> but the tunnel_send() for multicast tunnel do this with LSRR option
> is the tunnel_send() a standard tunnel ?? that anyone understand it ? or
> not ??? Thanx
Sorry; I couldn't find a tunnel_send() function to check this
against in the FreeBSD kernel sources. So I can
soheil h wrote:
> as in stevens' Tcp/Ip illustrated says when a router see an unknown option
> it must silently ignore it but when i put an option by type 253 len 12 and
> 10 byte of data
> some router on my path drop it
> how can i set an option an put 2 ip address in it that no router delete my
Andre Oppermann wrote:
> > Benchmark the driver.
> >
> > If it's fast, it doesn't collect the statistics.
>
> Come on, this is bullshit. whatever++ hardly makes any difference.
> There are other places where way more cycles are wasted for less.
You removed my "8-)" by truncating my statement, an
Andy Sparrow wrote:
> But these stats don't seem to be collected for at least some network card
> drivers, presumably because those drivers aren't collecting those stats, e.g.
> they don't #include , and thus don't allocate a mib structure or
> increment any counters in that structure.
>
> I can
Alfred Perlstein wrote:
> * Julian Elischer <[EMAIL PROTECTED]> [020603 12:41] wrote:
> > this is YET ANOTHER case for the Atomic reference counting ABI that
> > jhb has been talking about...
>
> I was the initial person to request an atomic_t API.
I think the request count was non-atomically in
Julian Elischer wrote:
> this is YET ANOTHER case for the Atomic reference counting ABI that
> jhb has been talking about...
No, they're not. They occur on m_copym, m_copypacket, and m_split.
In practice, these are called seperately in the down and up path,
and this isn't a problem (in the up
Joshua Goodall wrote:
> On Sat, May 18, 2002 at 05:48:19PM -0700, Terry Lambert wrote:
> > Joshua Goodall wrote:
> > > On Sat, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote:
> > > > No. TCP. RPC over UDP is really a silly idea. If you need
> > >
Joshua Goodall wrote:
> On Sat, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote:
> > No. TCP. RPC over UDP is really a silly idea. If you need
> > reliable delivery, then don't use a protocol with "unreliable"
> > as the first word of it's n
John Baldwin wrote:
> > This is actually what I was saying was bad: a static function
> > per mutex declaration.
>
> Umm, no, there is _one_ global function that we call. Why not check
> the actual code?
Are you talking about a P4 branch, and not the main repository?
> Why don't you read the c
John Baldwin wrote:
> On 18-May-2002 Terry Lambert wrote:
> > John Baldwin wrote:
> >> > God, it's annoying that a statically declared mutex is not
> >> > defacto initialized.
> >>
> >> Is it in solaris?
> >
> > It isn
Don Bowman wrote:
> > Andrew Gallatin writes:
> >> Kenneth D. Merry writes:
> >> >
> >> > I have released a new set of zero copy sockets patches, against
> -current
> >> > from today (May 17th, 2002).
> >
> > Hi Ken,
> >
> > I'm glad to see that you're still maintining this!
> >
> > Assuming th
John Baldwin wrote:
> > God, it's annoying that a statically declared mutex is not
> > defacto initialized.
>
> Is it in solaris?
It isn't in FreeBSD because of the need to link mutex'es into
the "witness protection program". 8-).
> > Yeah, I understand the "witness" crap (if it's there); tha
Attila Nagy wrote:
> > If the card on the receiving could not receive so many back to back
> > packets and looses one or more, nfs will get stuck retrying the same big
> > packet and the same thing happening over and over.
>
> Yep, but that's not my case. If this would be the problem, I guess
> c
Attila Nagy wrote:
> > Sending datagrams bigger than the MTU is a bad idea.
>
> It depends on what do you want to do with that NFS server :)
Sure. Maybe you want to use up it's mbufs by jamming the frag
reassembly queue for IP full of N-1 frags using 64K USP packets.
> I want to get out from
Andrew Reilly wrote:
> On Sat, 2002-05-18 at 18:53, Terry Lambert wrote:
> > Sending datagrams bigger than the MTU is a bad idea.
> >
> > I would be real tempted to drop the packets and send "don't fragment"
> > ICMP responses to beat up anyone who abu
Alfred Perlstein wrote:
> * Kenneth D. Merry <[EMAIL PROTECTED]> [020517 23:31] wrote:
> > The problem here is that the mutex needs to be initialized before I can
> > acquire it, and there's going to be a race between checking to see
> > whether it has been initialized and actually initializing it
Attila Nagy wrote:
> > > the "em" driver (if "gx" is already in the initial plan), because it
> > > reportedly works better (for example I couldn't do NFS serving with UDP
> > > packets bigger than the MTU with that, while the "em" driver works OK).
> >
> > It *does* frag packets bigger than the M
Attila Nagy wrote:
> Although I'm not a coder myself, I would also look for the way to patch
> the "em" driver (if "gx" is already in the initial plan), because it
> reportedly works better (for example I couldn't do NFS serving with UDP
> packets bigger than the MTU with that, while the "em" driv
"M. Warner Losh" wrote:
> : Actually, it appears I'm wrong, and you just haven't read the
> : message yet. Apparently there have been some commits which
> : fix your problem for you (though they may be limited to -current).
>
> Nope. They have been MFC'd as of April 30th or so. The entire wi
>
Martin Minkus wrote:
> Perhaps when I have some spare time I can go look into the wi driver.
> And perhaps your right, firmware changes on the orinoco cards are the
> cause of this; I have flashed mine to 8.1 (or whatever the latest
> firmware is, 8.something). My white wavelan cards were original
Martin Minkus wrote:
> But it's a standard WaveLAN/Orinico card, which is what the wi driver is
> intended for?
>
> I never had to worry about any of this when I had the old white/bronze
> 2mbit wavelan cards, but with silver and gold cards, its been nothing
> but fun and games
I suppose I c
Bill Fumerola wrote:
> this is about representing within the freebsd network stack ethernet
> cards that support multiple (>1) unicast mac addresses through either
> multiple perfect filter entries or a multicast filter borrowed to serve
> such a purpose. until freebsd has a way of supporting this
Thomas David Rivers wrote:
> > I guess we need to see a packet trace for a Windows machine
> > being successful, and a FreeBSD machine being unsuccessful,
> > in order to run a side-by-side comparison.
>
> Believe me! I've asked for such a thingy... apparently,
> the "magic software" needed t
Archie Cobbs wrote:
> [ note: freebsd-hackers being removed from the cc: list ]
> Thomas David Rivers writes:
> > mpd fails as well... with something very similar... it seems to
> > send a CCP configuration request and simply gets no answer
> > back from the Microsoft server. From the VPN log
Archie Cobbs wrote:
> Thomas David Rivers writes:
> > If I add
> > enable MSChapV2
> > in /etc/ppp/ppp.conf - then our ppp client requires that the
> > peer (the Microsoft VPN server) authenticate using MSChapV2. But,
> > the Microsoft VPN peer refuses that (it's configured to not u
mark tinguely wrote:
> > Right now, ip_tos (and ipf_tos) is an 8 bit value, of which only
> > the first 6 bits are used in the hash, while the hash value pass
> > itself is a 32 bit value (in most cases: it's "unsigned"). I'd
> > like to push the value into the same space as the src.s_addr
>
David Malone wrote:
> > A shutdown guarantees that the data is transferred from the socket
> > buf to the TCP buf. The real question here is how you get to the
> > state you claim is happening: the so isdisconnected() should stall
> > the calling process until the data has drained, if this is the
] When soisdisconnected is called on a socket, the connection is
] marked as broken the socket can't recieve or send any more data.
] As far as I can tell, any data which is queued for output cannot
] be sent, but remains queued in the socket until it is closed.
]
] The patch below makes soisdisc
Matt wrote:
> You may try some other kind of load balance and fail safe from
> www.xgforce.com. It's a layer 3 and layer 7 global clustering software for
> FreeBSD.
Wrong kind of "load balancing". The original poster wanted
channel bonding, not server load balancing.
The layer 3 in the referen
It seems to me that it would be useful to break out the ip_tos
field in the ipflow_lookup() function, just like in the ipflow_hash()
function, and make it an unsigned long (the packing of the structure
makes it a 32 bit value (or 64 bit, on Alpha) anyway.
This also means calling the mtod() (which
Does anyone know of any 8 port or better ethernet cards? The ideal
card (IMO) would be:
o Plug into a PCI slot
o At least 8 ports
o The 8 ports would not be on the mounting bracket, but would
instead be externally mounted (ideally, with a rackmount
front panel
Fengrui Gu wrote:
> There is something interesting. I accidentally started a
> ping command(ping data sender side) from data receiver side.
> As you know, ping will continue running until you stop it.
>
> I started netperf again from data sender side. You know what?
> The link seems more stable w
Luigi Rizzo wrote:
> i recently (late february) made some commits that among other
> things enabled the native bridging in FreeBSD to work on vlans.
> Both on -stable and -current.
OK, then I'm out of date.
Does this work with ip.fastforwarding?
-- Terry
To Unsubscribe: send mail to [EMAIL PRO
Julian Elischer wrote:
>
> failing that, I have just had "contributed"
> some code that produces an actual "vlan" netgraph node.
> You attach it to the ethernet node.. I'm still
> reading it to work out what it does..
Is this the "VLAN implemented in Netgraph" thing you were
talking about last D
Julian Elischer wrote:
> > Would imply it should just work to bridge vlan's via netgraph bridging.
> > As Archie said I have not tested this to prove how it does or does not
> > work since I haven't had a need to try it.
>
> I don't know, but it may have problems setting promiscuous mode..
> is t
Archie Cobbs wrote:
> Terry Lambert writes:
> > Bridging doesn't work with the vlanX interface currently in FreeBSD.
>
> Why not?
>
> I believe you, I've just never used vlans and always assumed
> that they acted like normal Ethernet interfaces.
According to
Terry Lambert wrote:
> Bridging doesn't work with the vlanX interface currently in
> FreeBSD.
>
> Julian promised (last December) that he would be committing a
> VLAN netgraph node for doing VLAN "the right way", but I have
> not seen anything. I tried to ping
"Peter J. Blok" wrote:
> I'd like to accomplish the following: I have two locations, connected via an
> IPSEC tunnel. Is it possible to connect the vlans at both ends through the
> tunnel.
>
> Is this possible with existing software? What would it take to do something
> like this?
Bridging does
Maksim Yevmenkin wrote:
> it does _exactly_ the same thing as patch i sent. the idea is
> to set "n->m_len" to zero. in this particular part of the code
> "n" is not modified. only "n->m_next". so i do not see any
> difference except your patch is 4 lines :)
Yours is less efficient.
-- Terry
Bill Fenner wrote:
> >Just for the heck of it, I started reading through ip_input.c to see how
> >hard this would be to do. Haven't got there yet, I saw something odd:
> >the variables ip_nfragpackets and nipq look *awfully* similar.
>
> So do the commit logs for the revisions in which each was
Makoto Matsushita wrote:
> Have you ever contact to Cho-san, the author of ALTQ? He is also a
> FreeBSD committer ([EMAIL PROTECTED]), and may willing to help you if he
> have enough time to do.
>
> ALTQ implementation is already integrated into KAME; maybe KAME guys
> can help you. I've heard
Andre Oppermann wrote:
> The plan is to first research and identify all issues with the currect
> networking stack in FreeBSD (1 month).
Here are some that I think need to be addressed.
o Can't make more that 64k outbound connections, without
heroic measures, even with multiple IP
Julian did some nice QOS work at Whistle that he always shushes
me when I mention it. You should beat him over the head for it.
It's not necessarily miscible with AltQ, but it had the effect
of controlling the amount of buffer space taken on the remote
end of a slow link, so that a single transf
Bill Fumerola wrote:
> i think that ip_fw_chk() taking _8_ arguments is getting a bit obscene.
ip_fw_chk should be obscene and not heard? 8-).
> we're talking about an optimization that less then .1% of our userbase
> will ever take advantage of v. a pessimization (additional argument in
> the
Bill Fumerola wrote:
> On Thu, Mar 07, 2002 at 03:51:41AM -0800, Julian Elischer wrote:
> > what would be even nicer is if ipfw found the cached entry and passed it
> > back to ip_input so it didn't need to :-)
>
> i think this entire idea of cacheing it in ip_input() is a bad idea, no
> offense
Julian Elischer wrote:
> what would be even nicer is if ipfw found the cached entry and passed it
> back to ip_input so it didn't need to :-)
This is the approach I intended.
The problem is that there are cases where you want the inpcb
for additional processing (e.g. ipfw), and cases where ther
There are redundant calls to the in_pcblookup_hash() in the
ip_fw_chk() function called via (*ip_fw_chk_ptr)() in the
ip_input path.
Would it be useful to modify the (*pr_input) function pointer
in the struct ipprotosw to take a fourth argument (perhaps it
should be cast to a "void *" to keep it
Harti Brandt wrote:
> TL>> > is there any way to get at the if_multiaddrs list from user space (except
> TL>> > for digging through the kernel with kvm).
> TL>>
> TL>> I'm affraid not.
> TL>
> TL>Actually, the easiest way is to remember the things when you
> TL>set them in the first place.
>
> Th
Ruslan Ermilov wrote:
> [Redirected to -net with -hackers Bcc:ed]
> > is there any way to get at the if_multiaddrs list from user space (except
> > for digging through the kernel with kvm).
>
> I'm affraid not.
Actually, the easiest way is to remember the things when you
set them in the first pla
[ ... Moved to -net ... ]
"James E. Housley" wrote:
> I am just trying to count bytes in and out, too keep track of usage and
> head off a large overage and a larger bill then necessary. Counting
> packets is worthless. But just do the math. With a GigE NIC, at what
> data rate do you start ov
Luigi Rizzo wrote:
>
> On Sat, Oct 27, 2001 at 04:52:54AM -0500, Mike Silbersack wrote:
> ...
> > Summary: The patch Terry posted was to loop a few more times in the
> > interrupt handler. I was going to commit it this weekend for the dc
> > driver, but it looks like Luigi's work overshadows th
1 - 100 of 121 matches
Mail list logo
