Re: Allocating AF constants for vendors.

2007-09-04 Thread Randall Stewart
Alfred Perlstein wrote: * Bruce M. Simpson <[EMAIL PROTECTED]> [070904 03:08] wrote: As you can see we are defering the "bloat". Does that make sense? I follow but it still doesn't really make sense. Granted, you are deferring the growth of arrays sized off AF_MAX but only ever by 1 slot.

Re: Allocating AF constants for vendors.

2007-09-04 Thread Alfred Perlstein
* Randall Stewart <[EMAIL PROTECTED]> [070904 13:22] wrote: > Alfred Perlstein wrote: > >* Bruce M. Simpson <[EMAIL PROTECTED]> [070904 03:08] wrote: > > > >>>As you can see we are defering the "bloat". > >>>Does that make sense? > >>> > >> > >>I follow but it still doesn't really make sense. > >>

Re: questions wrt ng_netflow

2007-09-04 Thread Weiguang Shi
Thanks! That all make sense. Wei - Original Message From: Gleb Smirnoff <[EMAIL PROTECTED]> To: Weiguang Shi <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED]; freebsd-net@FreeBSD.org Sent: Saturday, September 1, 2007 1:51:38 AM Subject: Re: questions wrt ng_netflow Weiguang, sorry for lat

Re: Killing IPTOS_CE and IPTOS_ECT

2007-09-04 Thread Rui Paulo
Bruce M. Simpson wrote: Rui Paulo wrote: Well, I was asking for comments regarding on the usage of these flags. I was hoping to commit ip.h along with TCP ECN. This doesn't really need to be before the branch, I think. Looks fine to me. ECN would be a useful feature to have. AFAIK nothing e

Re: Killing IPTOS_CE and IPTOS_ECT

2007-09-04 Thread Bruce M. Simpson
Rui Paulo wrote: Well, I was asking for comments regarding on the usage of these flags. I was hoping to commit ip.h along with TCP ECN. This doesn't really need to be before the branch, I think. Looks fine to me. ECN would be a useful feature to have. AFAIK nothing else uses these flags. A

Re: Killing IPTOS_CE and IPTOS_ECT

2007-09-04 Thread Rui Paulo
Andre Oppermann wrote: Rui Paulo wrote: Hi, I'm working on TCP ECN support and I would like to kill these defines from netinet/ip.h #if 1 /* ECN RFC3168 obsoletes RFC2481, and these will be deprecated soon. */ #define IPTOS_CE0x01 #define IPTOS_ECT 0x02 #endif T

Advance IST by 30 minutes, save Rs.10 bn: scientists/Kalyani to acquire German wind firm/GAIL seeks nod for pipeline gas in 230 cities

2007-09-04 Thread si dailydose
SiliconIndia Daily Dose | September 04 2007 >> TOP NEWS [1]Advance IST by 30 minutes, save Rs.10 bn: scientists A group of scientists have suggested that the Indian Standard Time (IST) be s

Re: kern/116077: 6.2-STABLE panic during use of multi-cast networking client

2007-09-04 Thread Bruce M Simpson
The following reply was made to PR kern/116077; it has been noted by GNATS. From: Bruce M Simpson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: kern/116077: 6.2-STABLE panic during use of multi-cast networking client Date: Tue, 04 Sep 2007 14:17:53 +0100 I wrote this, but I may n

Re: Killing IPTOS_CE and IPTOS_ECT

2007-09-04 Thread Andre Oppermann
Rui Paulo wrote: Hi, I'm working on TCP ECN support and I would like to kill these defines from netinet/ip.h #if 1 /* ECN RFC3168 obsoletes RFC2481, and these will be deprecated soon. */ #define IPTOS_CE0x01 #define IPTOS_ECT 0x02 #endif The are outdated and shou

Re: Allocating AF constants for vendors.

2007-09-04 Thread Alfred Perlstein
* Bruce M. Simpson <[EMAIL PROTECTED]> [070904 03:08] wrote: > >As you can see we are defering the "bloat". > >Does that make sense? > > > > I follow but it still doesn't really make sense. > > Granted, you are deferring the growth of arrays sized off AF_MAX but > only ever by 1 slot. > What i

Re: kern/116077: 6.2-STABLE panic during use of multi-cast networking client

2007-09-04 Thread remko
Synopsis: 6.2-STABLE panic during use of multi-cast networking client Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Tue Sep 4 11:17:55 UTC 2007 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr

Re: If_bridge and MST

2007-09-04 Thread Eygene Ryabinkin
Good day. Tue, Sep 04, 2007 at 11:07:22AM +0300, Shteryana Shopova wrote: > AFAIK, Cisco PVST is the predecessor of 802.1Q MSTP. If I remember > correctly one of the notable differences between the two is that with > Cisco PVST BPDUs are send for every spanning tree instance (also > tagged?) while

Re: Allocating AF constants for vendors.

2007-09-04 Thread Bruce M. Simpson
Alfred Perlstein wrote: Can you merge them into the list in such a way that AF_MAX does not need to slide forward? Or do they need to be referenced from within the kernel tree itself? They are refenced inside the kernel. Let me rephrase that: are protocol domains attached in the kern

Re: Network stack locking question

2007-09-04 Thread Bruce M. Simpson
Ivo Vachkov wrote: panic: mtx_lock() of spin mutex 'some_strange_chars' ../../../net/route.c:114 ether_demux() at ether_demux+ my_func() at my_func+ rtalloc_ign() at rtalloc_ign+ _mtx_lock_flags() at _mtx_lock_flags+ panic() at panic+ I do not include GIANT_REQUIRED in my code. Can you propose

Network stack locking question

2007-09-04 Thread Ivo Vachkov
Hello all, I'm currently working on some ipv6 related code. At some point I have to do a routing lookup and I meet following problem: panic: mtx_lock() of spin mutex 'some_strange_chars' ../../../net/route.c:114 cpuid = 0 KDB: enter: panic [thread pid 17 tid 100021 ] Stopped at kdb_enter+0x3

Re: If_bridge and MST

2007-09-04 Thread Tom Judge
Shteryana Shopova wrote: On 9/4/07, Andrew Thompson <[EMAIL PROTECTED]> wrote: On Mon, Sep 03, 2007 at 10:21:20PM +0100, Tom Judge wrote: Andrew Thompson wrote: On Mon, Sep 03, 2007 at 02:11:59PM +0100, Tom Judge wrote: Hi, I was wondering if if_bridge had been taught how to speak multiple i

Re: If_bridge and MST

2007-09-04 Thread Shteryana Shopova
On 9/4/07, Andrew Thompson <[EMAIL PROTECTED]> wrote: > On Mon, Sep 03, 2007 at 10:21:20PM +0100, Tom Judge wrote: > > Andrew Thompson wrote: > > >On Mon, Sep 03, 2007 at 02:11:59PM +0100, Tom Judge wrote: > > >>Hi, > > >> > > >>I was wondering if if_bridge had been taught how to speak multiple > >