On Tue, 14-Apr-2015 at 10:01:16 -0400, Mike Tancsa wrote:
> On 4/14/2015 1:54 AM, Andre Albsmeier wrote:
> >
> > Is this an em specific issue or should one avoid TSO generally
> > at the moment? That is, should I disable it on machines with
> > msk (and maybe other)
On Wed, 15-Apr-2015 at 10:18:12 -0400, Mike Tancsa wrote:
> On 4/15/2015 1:42 AM, Andre Albsmeier wrote:
> > On Tue, 14-Apr-2015 at 10:01:16 -0400, Mike Tancsa wrote:
> >> On 4/14/2015 1:54 AM, Andre Albsmeier wrote:
> >>>
> >>> Is this an em specif
On Tue, 14-Apr-2015 at 10:01:16 -0400, Mike Tancsa wrote:
> On 4/14/2015 1:54 AM, Andre Albsmeier wrote:
> >
> > Is this an em specific issue or should one avoid TSO generally
> > at the moment? That is, should I disable it on machines with
> > msk (and maybe other)
On Mon, 13-Apr-2015 at 09:06:16 -0400, Mike Tancsa wrote:
> On 4/13/2015 6:16 AM, Andre Albsmeier wrote:
> > I don't want to say that I can easily reproduce it but chances are
> > quite good when I transfer a lot of stuff over the network _AND_
> > the CPU is heavily loa
Hi,
em0 = '82574L Gigabit Network Connection':
em0: port 0xd000-0xd01f mem
0xf050-0xf051,0xf052
-0xf0523fff irq 17 at device 0.0 on pci5
em0: Using MSIX interrupts with 3 vectors
OS = 9.3-STABLE #2: Wed Apr 1 07:20:47 CEST 2015
Sometimes em0 freezes and comes back about 1 minute
On Wed, 11-Feb-2015 at 20:10:26 +1100, Ian Smith wrote:
> On Tue, 10 Feb 2015 19:34:20 +0100, Andre Albsmeier wrote:
> > On Wed, 11-Feb-2015 at 04:33:15 +1100, Ian Smith wrote:
> > > On Tue, 10 Feb 2015 14:26:52 +0100, Andre Albsmeier wrote:
> > > > On Tue, 10-F
On Wed, 11-Feb-2015 at 04:33:15 +1100, Ian Smith wrote:
> On Tue, 10 Feb 2015 14:26:52 +0100, Andre Albsmeier wrote:
> > On Tue, 10-Feb-2015 at 13:49:23 +0300, Lev Serebryakov wrote:
> > > On 10.02.2015 00:21, Andre Albsmeier wrote:
> > >
>
On Tue, 10-Feb-2015 at 13:49:23 +0300, Lev Serebryakov wrote:
> On 10.02.2015 00:21, Andre Albsmeier wrote:
>
> > The ipfw man page says:
> >
> > Usually a simple rule like:
> >
> > # reassemble incoming fragments ipfw add reass all from any to any
&g
r make this work. It eats all fragments but
the resulting final packet never makes it. I am back to
ipfw -q add 1 pass udp from any to $myip frag in recv $ifc
as I need it only for UDP. Frag reassembly in pf works well
on the other hand...
-Andre
> ...
>
> --
> Freddie Ca
of a function. Also declaration-initialization is not
really permitted by style(9) even though it is used in a few places.
--
Andre
+
+ *refcnt = 1;
m->m_ext.ext_buf = (caddr_t)mem;
m->m_data = m->m_ext.ext_buf;
m->m_fl
the box while not killing
small ones. Lets say it covers > 90% of our actual users and use cases.
If you have special requirements then you may have to tune these values,
but if you known exactly what your system is going to do, then chances
are you&
On 29.08.2013 01:42, Alan Somers wrote:
On Mon, Aug 26, 2013 at 2:40 PM, Andre Oppermann wrote:
On 26.08.2013 19:18, Justin T. Gibbs wrote:
Hi Net,
I'm an infrequent traveler through the networking code and would
appreciate some feedback on some proposed solutions to issues Spectr
of reliable GC like ("passive
serialization" or other
similar not-to-pronounce-words about Linux and lockless objects).
Rmlocks are our secret weapon and just as good.
P.S. Attached patches are 1) for 8.x 2) mostly 'hacks' showing roughly how can
this be done and what
benefit can be achieved.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ot binding TX to a core is
a win. So we will pretty much end up with one lock per TX ring to protect the
DMA descriptor structures.
We're still far way from having to worry about this TX issue. The big win
is the RX queue - socket - application affinity (to the same core).
--
Andre
_
ill benchmarking the impact of this change. Assuming we
can get decent flow ID data, this should only impact outbound UDP, since the
stack doesn't provide a flow ID in this case.
Are there other checksums we should be looking at in addition to FNV?
siphash2
On 26.08.2013 16:46, Luigi Rizzo wrote:
On Mon, Aug 26, 2013 at 04:27:59PM +0200, Andre Oppermann wrote:
...
1. lle lock to rmlock.
2. if_addr and IN_ADDR locks to rmlocks.
3. routing table locking (rmlocks, and by doing away with rtentry locks and
refcounting
through copy-out on
On 25.08.2013 16:42, Adrian Chadd wrote:
On 24 August 2013 10:09, Andre Oppermann mailto:an...@freebsd.org>> wrote:
On 24.08.2013 19:04, Adrian Chadd wrote:
I'm very close to starting an mbuf batching thing to use in a few
places like receive,
transmit and
ary/windows/hardware/jj853325%28v=vs.85%29.aspx
--
Andre
http://svnweb.freebsd.org/base?view=revision&revision=254336
http://svnweb.freebsd.org/base/user/np/cxl_tuning/sys/netinet/tcp_lro.c?r1=254336&r2=254335&pathrev=254336
http://svnweb.freebsd.org/base/user/np/cxl_tuning/sys/netin
ss test there. :)
I'd strongly recommend fixing a number of other places and collect
lower hanging fruit before starting with mbuf batching.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To uns
ter configuration to default on. It's not
netmap that does it but the driver. It seems to happen in or around
ixgbe_setup_vlan_hw_support().
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsu
On 23.08.2013 09:13, Juli Mallett wrote:
On Fri, Aug 23, 2013 at 12:02 AM, Andre Oppermann mailto:an...@freebsd.org>> wrote:
On 23.08.2013 00:36, Harika Tandra wrote:
Hi all,
I am running Netmap with "intel 10G 82598EB" card in promiscuous mode.
feature and only complicates things. Especially in the context of multi-vlan
stacking. Doing it in software would be in fact just as fast remove a bit of
code
from the drivers.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.
On 21.08.2013 22:52, Navdeep Parhar wrote:
On 08/21/13 13:44, Andre Oppermann wrote:
On 21.08.2013 21:40, Navdeep Parhar wrote:
On 08/21/13 12:22, Andre Oppermann wrote:
On 21.08.2013 20:23, Navdeep Parhar wrote:
I believe we need an extra patch to get M_NOFREE correct. I've had it
fo
location and cause atomic bus lock cycles as well as
a lot of cache line invalidations across cores. The same is true for refcounts.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, sen
On 21.08.2013 21:40, Navdeep Parhar wrote:
On 08/21/13 12:22, Andre Oppermann wrote:
On 21.08.2013 20:23, Navdeep Parhar wrote:
I believe we need an extra patch to get M_NOFREE correct. I've had it
forever in some of my internal repos but never committed it upstream
(just plain f
+* Do not free if the mbuf is embedded in the cluster.
+*/
+ if (m->m_flags & M_NOFREE) {
+ m_tag_delete_chain(m, NULL);
return;
+ }
/*
* Free this mbuf back to the mbuf zone with all m_ext
--
Andre
_
been
re-broken?
There may be some window update dynamics going on together with LRO received
ACK compression.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
sh them up and work out the final kinks. The speedup
and reduction in overhead is significant.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
hen are you next at a BSD developer summit / conference? Will you
be at Malta?
He has submitted a talk about netmap and was accepted, so I surely do hope
that he shows up. ;)
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On 21.08.2013 18:38, Navdeep Parhar wrote:
On 08/21/13 08:08, Andre Oppermann wrote:
On 20.08.2013 00:38, Peter Grehan wrote:
If there's an alternative to M_NOFREE, I'd be more than happy to use
that.
Set up your own (*ext_free) function and omit freeing of the mbuf
itself.
vided by cperciva.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
f these issues separately, but since
they are all related, I thought it would be easier for others to
evaluate them with context.
Fine with me and no objections.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listi
On 20.08.2013 05:13, Julian Elischer wrote:
On 8/20/13 6:38 AM, Peter Grehan wrote:
Hi Andre,
(moving to the more appropriate freebsd-net)
I'm sorry for ambushing but this stuff has to be done. I have provided
an alternative way of handling it and I'm happy to help you with you
On 20.08.2013 00:38, Peter Grehan wrote:
Hi Andre,
(moving to the more appropriate freebsd-net)
I'm sorry for ambushing but this stuff has to be done. I have provided
an alternative way of handling it and I'm happy to help you with your
use case to make it good for you and to p
l packet header parsing from the drivers for offload setup.
Others:
Mbuf initialization is unified through m_init() and m_pkthdr_init() to avoid
duplication. m_free_fast() is removed for lack of usage.
Patch is available here:
http://people.freebsd.org/~andre/mbuf-adjustments-20130821.dif
On 14.08.2013 04:36, Lawrence Stewart wrote:
Hi Andre,
[RE team is BCCed so they're aware of this discussion]
On 07/06/13 00:58, Andre Oppermann wrote:
Author: andre
Date: Fri Jul 5 14:58:24 2013
New Revision: 252789
URL: http://svnweb.freebsd.org/changeset/base/252789
Log:
MFC r2
top of kernel threads so it's mostly a matter of
nicely integrating and exposing an API for it.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "f
way to shutdown the ithread.
Yes, when done a well-tested, stable and performant template will be provided.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On 05.08.2013 23:53, Luigi Rizzo wrote:
On Mon, Aug 05, 2013 at 11:04:44PM +0200, Andre Oppermann wrote:
On 05.08.2013 19:36, Luigi Rizzo wrote:
...
[picking a post at random to reply in this thread]
tell whether or not we should bail out).
Ideally we don't want to have any locks i
d fxp, bge and igb drivers in my tcp_workqueue
branch to test these concepts. Not all of it is committed or fully up to date.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
t
[1] for an example.
Does anyone know if there is a generic mechanism, or each driver
reimplements its own way ?
We desperately need a saner ifnet/driver interface. I think andre@
had some previous work in this area (and additional plans as well?).
Yes. I have received a grant from the FF to l
x1-x8 at 5 GT/s. AFAIK you can't event buy the 82598 anymore.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ation accepting them. Typically you either suffer from a DoS
attack or your server is undersized for the amount of traffic it is receiving.
A change to rate-limit the number of these messages is in the works to prevent
it filling from the logs too fast.
--
Andre
___
On 16.07.2013 13:32, Loganaden Velvindron wrote:
On Thu, Jul 11, 2013 at 10:36:22AM +0200, Andre Oppermann wrote:
On 10.07.2013 15:18, Fabian Keil wrote:
Andre Oppermann wrote:
We have a SYN cookie implementation for quite some time now but it
has some limitations with current realities for
On 12.07.2013 10:25, Gleb Smirnoff wrote:
On Thu, Jul 11, 2013 at 05:43:09PM +0200, Andre Oppermann wrote:
A> >> Andriy for example would never have found out about this problem other
A> >> than receiving vague user complaints about aborted connection attempts.
A> >>
On 11.07.2013 17:04, Andriy Gapon wrote:
on 11/07/2013 17:28 Andre Oppermann said the following:
Andriy for example would never have found out about this problem other
than receiving vague user complaints about aborted connection attempts.
Maybe after spending many hours searching for the cause
On 11.07.2013 15:35, Gleb Smirnoff wrote:
On Thu, Jul 11, 2013 at 09:19:40AM +0200, Andre Oppermann wrote:
A> On 11.07.2013 09:05, Andriy Gapon wrote:
A> > kernel: sonewconn: pcb 0xfe0047db3930: Listen queue overflow: 193
already in
A> > queue awaiting acceptance
A> >
On 10.07.2013 15:18, Fabian Keil wrote:
Andre Oppermann wrote:
We have a SYN cookie implementation for quite some time now but it
has some limitations with current realities for window scaling and
SACK encoding the in the few available bits.
This patch updates and improves SYN cookies mainly
is important to determine if this is only
a temporary spike (micro-burst) or persistent condition.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
here for testing:
http://people.freebsd.org/~andre/syncookie-20130708.diff
Please enable TCP logdebug to see connection status reporting by the
changes.
Detailed discussion:
The purpose of SYN cookies is to encode all necessary session state
in the 32 bits of our initial sequence number to
ctice though.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
n "obscure" ALTQ mechanism having its own mbuf header field
as such. It must be a generic field that can be used by others as well.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
em are an indication that something is very wrong
with the packet or the caller.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
r of resources explaining this issue in more detail:
http://www.cisco.com/web/about/security/intelligence/network_performance_metrics.html
http://ekb.spirent.com/resources/sites/SPIRENT/content/live/FAQS/1/FAQ10597/en_US/How_to_Test_10G_Ethernet
create a first version of the patch
which manually walks the sack scoreboard each time through
siftr_siftdata() to sum the # bytes in each hole to ensure you don't
inadvertently introduce accounting bugs while developing the patch.
Patch v2 can incl
to it and bumps the overall packet
size as seen by the driver to 64K + sizeof(ether_hdr) and possibly
additional VLAN headers. If the bus_dma_tag size is set to 64K then
bus_dma mapping will fail for such maximum size packets.
--
Andre
Jack
On Sat, May 4, 2013 at 1:41 PM, Jack Vogel wrote:
instead of snd_max used? In case of a partial ack,
snd_nxt is readjusted for retransmit, that means, that it's closer to
snd_una. What is your opinion, how should this variable be calculated?
Unfortunately the pipe value isn't really calculated at the moment.
--
Andre
__
ation to cores is done at interrupt
registration time or driver attach time. It can be re-distributed
at run time on most architecture but I'm not sure we have an easily
accessible API for that.
--
Andre
___
freebsd-net@freebsd.org mailing list
http
rn Intel Core i[3-7] and AMD64
may actually improve with these changes. Unless more recent micro-archs
have been shown to exhibit the same regression we can't claim this change
was bad (other than for Pentium4).
--
Andre
ministat -s 242401.forwarding 242402.forwarding
x 242401.forwarding
pular
architectures.
For an estimate and time-series comparison your bench test is very
helpful though.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-ne
thing should
happen via sorta published API's the other firewall packages use as well.
Most important pfil hooks. The hardest part probably is to get the locking
right.
Please run changes to src/sys/net* through glebius@ and me (andre@) first
before committing. In most, if not all ca
e
there is new data to send prior to calling tcp_output()?
Yes. Based on your input the attached patch should fix it (untested).
--
Andre
Index: tcp_input.c
===
--- tcp_input.c (revision 249375)
+++ tcp_input.c (working copy)
@@ -25
On 09.04.2013 10:16, Peter Holm wrote:
On Mon, Apr 08, 2013 at 02:13:40PM +0200, Andre Oppermann wrote:
On 05.04.2013 13:09, Matt Miller wrote:
Hey Rick,
I believe Juan and I have root caused this crash recently. The t_state =
0x1, TCPS_LISTEN, in the link provided at the time of the
efore
we hit tcp_do_segment().
Could you please review the attached patch which handles it right
after the SO_ACCEPTCONN / syncache check?
--
Andre
Index: netinet/tcp_input.c
===
--- netinet/tcp_input.c (revision 2
?
Interesting triggering of the assertion... I can have a look in the
afternoon.
--
Andre
pho@ wrote:
I continued running the NFS tests and got this "panic: tcp_do_segment:
TCPS_LISTEN". It's the second time I get this panic with the same test
scenario, so it seems to be repro
On 04.04.2013 23:52, Kevin Day wrote:
On Feb 1, 2013, at 5:09 PM, Andre Oppermann wrote:
I'm working on a solution. Have to make sure that the chance to
crack a reduced cookie during its 30 seconds lifetime isn't too
high. That means involving our resident crypto experts for
ve
t on
highly loaded systems may be non-trivial, however it is not so easy to
implement.
--
Andre
I'll hopefully have some proper testing results later in the week.
-GAWollman
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/
On 18.03.2013 13:20, Alexander V. Chernikov wrote:
On 17.03.2013, at 23:54, Andre Oppermann wrote:
On 17.03.2013 19:57, Alexander V. Chernikov wrote:
On 17.03.2013 13:20, Sami Halabi wrote:
ITOH OpenBSD has a complete implementation of MPLS out of the box, maybe
Their control plane code is
st tricky place here is control plane.
However, making _fast_ MPLS switching is tricky too, since it requires chages
in our netisr/ethernet
handling code.
Can you explain what changes you think are necessary and why?
--
Andre
___
freebsd-net@freebs
it to arch@
twice now I think. :( It also fixes interrupt filters to really work properly
and be on by default.
Do you have a link to that patch?
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To u
NFS server seems to depend somewhat
on that by requiring atomicity on a RPC send. I have to trace the mbuf
path through NFS to the socket to be sure. The code is slightly opaque
though.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.fr
On 11.03.2013 00:46, Rick Macklem wrote:
Andre Oppermann wrote:
On 10.03.2013 03:22, Rick Macklem wrote:
Garett Wollman wrote:
Also, it occurs to me that this strategy is subject to livelock. To
put backpressure on the clients, it is far better to get them to
stop
sending (by advertising a
anymore
at allocation time.
Most modern high speed network cards can do scatter DMA and could
simply split up a received jumbo frame across as many normal mbuf
clusters as necessary.
For a temporary fix you could forgo using a MTU larger than 4096.
--
Andre
_
n't seem useful in this case?
These are just the limits for auto-tuning.
I'm no TCP guy, so suggestions w.r.t. how big soreserve() should be set
are welcome.
I'd have to look more at the NFS code to see what exactly is going on
and what t
On 10.03.2013 07:04, Garrett Wollman wrote:
< said:
Yes, in the past the code was in this form, it should work fine Garrett,
just make sure
the 4K pool is large enough.
[Andre Oppermann's patch:]
if (adapter->max_frame_size <= 2048)
adapter-> rx_mbuf_sz = MCLBYTES;
h it and thanks for running on the "bleeding edge" so
these issues get identified, rick
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
e a patch I can certainly build it in to our kernel
and have it ready the next time the production server crashes. I'd
like it to be at least a *little* tested by someone else beforehand,
though.
This should do the trick.
--
Andre
Index: dev/ixgbe
27;t break down
when the RX ring can't be filled to the max.
I recently got yelled at for suggesting to remove jumbo > PAGE_SIZE.
However your case proves that such jumbo frames are indeed their own
can of worms and should really only and ex
On 07.03.2013 16:34, Alexander V. Chernikov wrote:
On 07.03.2013 17:51, Andre Oppermann wrote:
On 07.03.2013 14:38, Ermal Luçi wrote:
Isn't it better to teach the routing code about metrics.
Routing daemons cope better this way and they can handle this.
So the policy of this behaviour c
On 07.03.2013 20:27, Krzysztof Barcikowski wrote:
W dniu 2013-03-07 18:09, Andre Oppermann pisze:
On 07.03.2013 17:54, Nick Rogers wrote:
I'm not sure. I have not explicitly enabled/disabled it. I am using
the GENERIC kernel from 9.1 plus PF+ALTQ.
# sysctl net.inet.flowtable.enable
s
ind much information
about this for FreeBSD 9.x
It's not compiled in GENERIC on 9.x because it had/has some stability
issues. I just wanted to make sure that the problem really come out
of the arpresolve area before digging into it.
--
Andre
On Wed, Mar 6, 2013 at 10:27 AM, Andre Opp
On 07.03.2013 14:54, Alexander V. Chernikov wrote:
On 07.03.2013 15:55, Andre Oppermann wrote:
On 07.03.2013 12:43, Alexander V. Chernikov wrote:
On 07.03.2013 11:39, Andre Oppermann wrote:
This brings up a long standing sore point of our routing code
which this patch makes more pronounced
On 07.03.2013 14:38, Ermal Luçi wrote:
On Thu, Mar 7, 2013 at 12:55 PM, Andre Oppermann mailto:an...@freebsd.org>> wrote:
On 07.03.2013 12:43, Alexander V. Chernikov wrote:
On 07.03.2013 11:39, Andre Oppermann wrote:
On 07.03.2013 07:34, Alexander V. Chernikov
On 07.03.2013 12:43, Alexander V. Chernikov wrote:
On 07.03.2013 11:39, Andre Oppermann wrote:
On 07.03.2013 07:34, Alexander V. Chernikov wrote:
Hello list!
There is a known long-lived issue with interface routes
addition/deletion:
ifconfig iface inet 1.2.3.4/24 can fail if given prefix is
vent
the installed interface routes should be removed from the routing
table. The configured addresses though should persist and the
interface routes re-installed on a link-up event. What's your
opinion on it?
Other than these points I think your code is fine an
Courtland,
the arpresolve observation is very important. Do you have flowtable
enabled in your kernel?
--
Andre
On 06.03.2013 17:16, Adrian Chadd wrote:
Another instance of it..
Adrian
On 6 March 2013 07:21, Courtland wrote:
Has there been any progress on resolving this problem. Does
uting?
How frequent does this happen?
I'm trying to create a stack graph to see which parts of the network
stack are involved in handling your packet.
--
Andre
Please refer to these past posts for more examples and evidence of
other users experiencing this problem:
http://forums.f
On 05.03.2013 04:21, Lawrence Stewart wrote:
On 03/05/13 03:35, Andre Oppermann wrote:
On 26.02.2013 14:38, Lawrence Stewart wrote:
Hi Andre,
Hi Lawrence, :-)
A colleague and I spent a very frustrating day tracing an accounting bug
in the multipath TCP patch we're working on at CAIA
On 26.02.2013 14:38, Lawrence Stewart wrote:
Hi Andre,
Hi Lawrence, :-)
A colleague and I spent a very frustrating day tracing an accounting bug
in the multipath TCP patch we're working on at CAIA to a bug in
sbsndptr(). I haven't tested it with regular TCP yet, but I believe the
On 13.02.2013 15:26, Lawrence Stewart wrote:
On 02/13/13 21:27, Andre Oppermann wrote:
On 13.02.2013 09:25, Lawrence Stewart wrote:
The idea is useful. I'd just like to discuss the implementation
specifics a little further before recommending whether the patch should
go in as is to prov
ys my intention to axe the ss_flightsize
variables and replace them with a better mechanism. Andre swung the axe
before I did and 10.x is looming so it's a good time to discuss all of this.
The solution I came up with was to add a new socket option to disable idle
handling completely. That is, w
On 11.02.2013 19:56, Adrian Chadd wrote:
On 11 February 2013 03:18, Andre Oppermann wrote:
In general Google does provide quite a bit of data with their experiments
showing that it isn't harmful and that it helps the case.
Smaller RTO (1s) has become a RFC so there was very broad cons
On 12.02.2013 11:55, Andrey Zonov wrote:
On 2/11/13 3:18 PM, Andre Oppermann wrote:
Smaller RTO (1s) has become a RFC so there was very broad consensus in
TCPM that is a good thing. We don't have it yet because we were not fully
compliant in one case (loss of first segment). I've
s of first segment). I've fixed that a while
back and will bring 1s RTO soon to HEAD.
I'm pretty sure that Google doesn't ignore idle on their Internet facing
servers. They may have proposed a decay mechanism in the past. I'd have
to check the TCP
On 05.02.2013 22:40, John Baldwin wrote:
On Tuesday, February 05, 2013 12:44:27 pm Andre Oppermann wrote:
I would prefer to encapsulate it into its own not-so-much-congestion-management
algorithm so you can eventually do other tweaks as well like more aggressive
loss recovery which would fit
other sysctl. Doing a CC module like this is very easy.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On 05.02.2013 18:11, John Baldwin wrote:
On Wednesday, January 30, 2013 12:26:17 pm Andre Oppermann wrote:
You can simply create your own congestion control algorithm with only the
restart window changed. See (pseudo) code below. BTW, I just noticed that
the other cc algos don't do not
t 30 seconds. Forward
security isn't necessary as the syncookie secrets are completely random and
renewed every 30 seconds.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On 01.02.2013 23:54, Kevin Day wrote:
On Feb 1, 2013, at 4:39 PM, Andre Oppermann wrote:
This is not true. FreeBSD uses bits in the timestamp to encode all recognized
TCP options
including window scaling.
Sorry, you are correct here. Reading through a half dozen TCP implementations
in
.syncache.bucketlimit = 32
net.inet.tcp.syncache.cachelimit = 65536
These settings are a bit more complicated than they should be.
Going forward I have to take a closer look at the modifications
in 1/ and 2/ and possibly combinations of both. The main issue
is the tradeoff in cookie bits vs. cook
1 - 100 of 954 matches
Mail list logo
