Bruce,
> >In my case if_bridge drops off the packet because firewall fails to
> >recognize the packet as good: the interface that is passed to a
> >pfil_hooks is bad (I mean not the one expected).
> >
> The ifp which your patch changes is that of the mbuf chain when bridge_input
>determines it i
RFC 1191 says to increase the PMTU at some itnerval (15 minutes default)
next time a packet is sent, this will be used... and if PMTU is really
increased,
no ICMP error will be recieved. that shows an increase in the PMTU. I'm
trying to
understand if this mechanism is there in freebsd. any on this
Bruce M Simpson wrote:
Hi,
Thanks for your reply.
Yar Tikhiy wrote:
My concern is that, with possible callers of ether_input() being
not really *from* but *on behalf* of the interface, e.g., in Netgraph,
IFF_DRV_RUNNING can be a way for the interface driver to tell us:
I'm not ready yet, so do
On Saturday 03 March 2007 12:59 pm, Alessandro de Manzano wrote:
> On Fri, Mar 02, 2007 at 05:55:35PM -0500, Jung-uk Kim wrote:
> > > [EMAIL PROTECTED]:0:0:class=0x02 card=0x165914e4 chip=0x165914e4
> > > rev=0x21 hdr=0x00 vendor = 'Broadcom Corporation'
> > > device = 'BCM5750A
On Monday 05 March 2007 15:43, Andrew Gallatin wrote:
>
> John Baldwin writes:
> > > John has a patch that pins interrupt threads, etc, not sure what the
status
> > of
> > > that is. CC'd.
> >
> > Tested and around for over a year. Sent to people several times but no
> > benchmarking
Alexander Motin wrote:
Alex Povolotsky wrote:
After disabling windowing and setting net.graph's, mpd4 refuses to work
and no ng interfaces ever created
lowering both tunables to 128000 solved the problem, will look more.
Oops! I have missed
kern.ipc.maxsockbuf=1048576
, which is required befo
John Baldwin writes:
> > John has a patch that pins interrupt threads, etc, not sure what the
> > status
> of
> > that is. CC'd.
>
> Tested and around for over a year. Sent to people several times but no
> benchmarking has resulted. It lives in p4 in //depot/user/jhb/intr/...
>
>
As I understand it, it is not possible to detect upward changes in the path
MTU as there is no mechanism for a router to generate an error when a packet
is small enough to be accommodated by the MTU of the link to the next hop. I
may be wrong though.
RFC1191 section 6.3.
http://www.ietf.org/
One last note.. It looks like SCHED_4BSD does a decent job (on my
setup) w/o CPU binding, but SCHED_ULE requires CPU binding to get good
performance. W/o CPU binding, the best bandwidth I see using
SCHED_ULE is around 5.3Gb/s with one CPU mostly idle.. With CPU
binding, it is roughly 9Gb/s.
aditya kiran wrote:
Hi,
I'm just trying to understand the PMTU Discovery support
in FreeBSD. Is upward PMTU (increase in PMTU) is also
discovered when PMTU Discovery is enabled?
Thanks,
Aditya
As I understand it, it is not possible to detect upward changes in the
path MTU as there is no mechan
Robert Watson writes:
> On Mon, 5 Mar 2007, Andrew Gallatin wrote:
>
> > With the patch, we finally seem to be performance competative on the
> > receive
> > side with Linux x86_64 and Solaris/amd64 on this same hardware. Both of
> > those OSes do much better (saturate the link with jumb
On Monday 05 March 2007 13:29, Robert Watson wrote:
> On Mon, 5 Mar 2007, Andrew Gallatin wrote:
>
> > With the patch, we finally seem to be performance competative on the
receive
> > side with Linux x86_64 and Solaris/amd64 on this same hardware. Both of
> > those OSes do much better (saturate
On Mon, 5 Mar 2007, Andrew Gallatin wrote:
Robert Watson writes:
> On Mon, 5 Mar 2007, Andrew Gallatin wrote:
>
> > With the patch, we finally seem to be performance competative on the receive
> > side with Linux x86_64 and Solaris/amd64 on this same hardware. Both of
> > those OSes do much bet
Robert Watson writes:
> On Mon, 5 Mar 2007, Andrew Gallatin wrote:
>
> > With the patch, we finally seem to be performance competative on the
> > receive
> > side with Linux x86_64 and Solaris/amd64 on this same hardware. Both of
> > those OSes do much better (saturate the link with jumb
On Mon, 5 Mar 2007, Andrew Gallatin wrote:
With the patch, we finally seem to be performance competative on the receive
side with Linux x86_64 and Solaris/amd64 on this same hardware. Both of
those OSes do much better (saturate the link with jumbos) when CPU affinity
is used to bind the interr
Andre Oppermann writes:
> The patch is here:
>
> http://people.freebsd.org/~andre/soreceive_stream-20070302.diff
>
> Any testing, especially on 10Gig cards, and feedback appreciated.
I just tested with my standard mxge setup (details and data below).
This is *awesome*. Before your patch
Hi,
I'm just trying to understand the PMTU Discovery support
in FreeBSD. Is upward PMTU (increase in PMTU) is also
discovered when PMTU Discovery is enabled?
Thanks,
Aditya
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinf
Hi,
Eygene Ryabinkin wrote:
Sure, I can test it, but then I need to know what problems are cured
by your patch, or I just should watch if it will not break something.
My concern is that I want to make sure that all these changes to the
ether_input path work OK together.
The M_PROMISC flag
On Mon, Mar 05, 2007 at 02:41:59PM +, Bruce M Simpson wrote:
> Hi,
>
> Thanks for your reply.
>
> Yar Tikhiy wrote:
> >My concern is that, with possible callers of ether_input() being
> >not really *from* but *on behalf* of the interface, e.g., in Netgraph,
> >IFF_DRV_RUNNING can be a way for
On Mon, Mar 05, 2007 at 03:35:20PM +0100, Andre Oppermann wrote:
> Yar Tikhiy wrote:
> >On Mon, Mar 05, 2007 at 01:40:26AM +, Bruce M Simpson wrote:
> >>Yar Tikhiy wrote:
> >>>Now I see your point, thanks! Well, at least in theory, the driver
> >>>shouldn't call ether_input() if the interface
Bruce,
> >And a question: can anyone say if my patch will break some known
> >good behaviour and if the current behaviour of if_bridge is based
> >on some logic I am currently failing to understand.
> >
> I would greatly appreciate it if you could look at the combined M_PROMISC and
> 802.1p pat
Hi,
Thanks for your reply.
Yar Tikhiy wrote:
My concern is that, with possible callers of ether_input() being
not really *from* but *on behalf* of the interface, e.g., in Netgraph,
IFF_DRV_RUNNING can be a way for the interface driver to tell us:
I'm not ready yet, so don't believe anyone who p
Yar Tikhiy wrote:
On Mon, Mar 05, 2007 at 01:40:26AM +, Bruce M Simpson wrote:
Yar Tikhiy wrote:
Now I see your point, thanks! Well, at least in theory, the driver
shouldn't call ether_input() if the interface isn't running. OTOH,
the interface shouldn't be getting traffic if it's !UP. H
On Mon, Mar 05, 2007 at 01:40:26AM +, Bruce M Simpson wrote:
> Yar Tikhiy wrote:
> >
> >Now I see your point, thanks! Well, at least in theory, the driver
> >shouldn't call ether_input() if the interface isn't running. OTOH,
> >the interface shouldn't be getting traffic if it's !UP. However,
Eygene Ryabinkin wrote:
Will try to understand if it will cure my problem, thanks!
Attaching my patch, just in case if freebsd gnats will be down ;))
Thanks for this. It looks like Andrew may be in a better position to say
if this fix should go in or not.
It is possible that if bridge cha
On Sun, 4 Mar 2007, Alexander Motin wrote:
> Ian Smith wrote:
> > mpd4 -b syslogs the intro line, then sometimes another one, maybe two:
> >
> > Mar 4 20:03:16 paqi mpd: process 39879 started, version 4.1 ([EMAIL
> > PROTECTED] 20:51 3-Mar-2007)
> > Mar 4 20:03:16 paqi mpd: CONSOLE: lis
Current FreeBSD problem reports
Critical problems
Serious problems
S Tracker Resp. Description
a kern/38554 netchanging interface ipaddress doesn't seem to work
s kern/39937 netipstealth
27 matches
Mail list logo
