Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Jan 2005 11:38:10 -0800
From:      Julian Elischer <julian@elischer.org>
To:        Gleb Smirnoff <glebius@freebsd.org>
Cc:        net@freebsd.org
Subject:   Re: [TEST/REVIEW #2] ng_ipfw: node to glue together ipfw(4) and netgraph(4)
Message-ID:  <41F6A022.5060708@elischer.org>
In-Reply-To: <20050125082136.GC57248@cell.sick.ru>
References:  <20050124100717.GA47663@cell.sick.ru> <41F5FED1.B6EFD246@freebsd.org> <20050125082136.GC57248@cell.sick.ru>

next in thread | previous in thread | raw e-mail | index | archive | help


Gleb Smirnoff wrote:

>On Tue, Jan 25, 2005 at 09:09:53AM +0100, Andre Oppermann wrote:
>A> Style-wise there is only the space after "(void )..." in ip_fw_pfil.c
>A> for the ng_tee case which is too much.
>
>Ok.
>
>A> I don't like the arbitrary back-passing of errors from ng_ipfw.  I'm
>A> fine with EACCES, ENOMEM and ESRCH (if hook not connected) but nothing
>A> else.  Getting back any other error is very confusing and non-intuitive
>A> when looking at the error of an application having packets sunk there.
>
>So you want "return (0)" at end of ng_ipfw_input()? My vote is against.
>Julian, Brooks?
>

I don't think that errors should be "sometimes".
we all expect udp to silently discard packets..
and queued data can not return status..
If you want to return the fact that a queue is full somewhere,
 then we have messages for that.

>
>A> Why don't you prepend the m_tag within ip_fw2.c as altq and divert are
>A> doing it?  Dummynet should do the same to get it consistent again.
>
>Not sure that this is good. These tags are foreign to ipfw, they belong
>to other facilities.
>

I have no comment

>
>A> Just to confirm it, NG_SEND_DATA_ONLY() queues the packet unconditionally
>A> to unwind the stack?
>
>No. The stack will be unwinded when packet travels thru netgraph and returned
>back to ng_ipfw node. A new ISR will start with ng_ipfw_rcvdata(). This mode
>is configured in ng_ipfw_connect().
>
>  
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41F6A022.5060708>