[Differential] [Commented On] D1809: [sockbuf] Don't expose lock details when isn't needed

davide added a comment. I plan to commit this in two days or such, so if there are objections, please raise them. REVISION DETAIL https://reviews.freebsd.org/D1809 To: davide, kmacy, np, rrs, lstewart, rwatson Cc: freebsd-net ___ freebsd-net@freebsd

[Differential] [Commented On] D1805: [sockbuf] Don't access fields directly, use accessor functions

davide added a comment. I plan to commit this in two days or such, so if there are objections, please raise them. REVISION DETAIL https://reviews.freebsd.org/D1805 To: davide, kmacy, np, lstewart, rrs, rwatson Cc: emaste, freebsd-net ___ freebsd-net

Re: Intel 82574L (em)

... you can still use 1 TX/1 RX ring on -HEAD. If we turn on RSS in the driver and have it hardware hash things, then the netisr input routine will throw it into the right per-CPU queue and it'll distribute the work. (Someone could twist my arm to do this.) -adrian __

Re: Intel 82574L (em)

On Sat, Jan 31, 2015 at 5:11 AM, Sean Bruno wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf > > According to 7.1.11, this device does indeed have 2 queues for stuff and > or things. So, basic RSS w

[Bug 172675] [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hostcache.list) race condition causing memory corruption

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172675 --- Comment #8 from commit-h...@freebsd.org --- A commit references this bug: Author: jhb Date: Tue Feb 10 21:41:57 UTC 2015 New revision: 278534 URL: https://svnweb.freebsd.org/changeset/base/278534 Log: MFC 277709: Use an sbuf to gen

Re: Problems with IP fragments

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: > > > > > > > The ipfw man page says: > > > > > > > > Usua

Re: Problems with IP fragments

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: > > > > > The ipfw man page says: > > > > > > Usually a simple rule like: > > > > > > # reassemble incoming fragments

Re: Problems with IP fragments

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10.02.2015 16:26, Andre Albsmeier wrote: >> reass works for me, but kills all IPv6 packets, so it should be >> "reass ip4 from any to any in [recv $iface]" > > Hmm, I tried again with ipv4 but this doesn't help (I don't use v6 > anyway here). B

Re: Problems with IP fragments

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 > > in > > > > is all you need at the beginnin

Re: Problems with IP fragments

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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 > in > > is all you need at the beginning of your ruleset. > > However,

[Differential] [Commented On] D1815: Evaluate packet size after the firewall had its chance

kristof added a comment. >>! In D1815#3, @ae wrote: > Since you are in ip6_forward(), this means ip6_input() has already checked > this packet and PFIL had a chance to handle this packet. > IPv6 router should not do reassembling fragmented packets and do new > fragmentation of them, but if you w