Dear Alexander,
If nobody objects I plan to commit this change at the end of next week.
LLE_RNLOCK(la); should be LLE_RLOCK(la); in arpresolve
Kind regards,
Ingo Flaschberger
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org
On 8 November 2012 15:55, Andre Oppermann wrote:
> At the risk of repeating myself: when a routed packet is fragmented
> the payload (layer 4, eg. TCP/UDP/SCTP) is NOT recalculated or changed
> or anything else. It remains as originally calculated by the sender
> unchanged in the first fragment
Synopsis: [netinet] [patch] icmp forward bandwithlimit
Responsible-Changed-From-To: freebsd-net->andre
Responsible-Changed-By: andre
Responsible-Changed-When: Fri Nov 9 00:00:22 UTC 2012
Responsible-Changed-Why:
Take over.
http://www.freebsd.org/cgi/query-pr.cgi?pr=173478
___
Synopsis: [socket] [patch] IPV6_USE_MIN_MTU and TCP is broken
Responsible-Changed-From-To: freebsd-net->andre
Responsible-Changed-By: andre
Responsible-Changed-When: Thu Nov 8 23:58:17 UTC 2012
Responsible-Changed-Why:
Take over.
http://www.freebsd.org/cgi/query-pr.cgi?pr=173444
On 09.11.2012 00:32, Adrian Chadd wrote:
On 8 November 2012 06:34, Andre Oppermann wrote:
TCP/UDP doesn't (want to) generate any fragments at all and tries
to avoid it at almost all cost. We want to send very large packets
and have the NIC fragment/segment it (TSO/UDP frag offload).
What ab
Old Synopsis: IPV6_USE_MIN_MTU and TCP is broken
New Synopsis: [socket] [patch] IPV6_USE_MIN_MTU and TCP is broken
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Nov 8 23:48:35 UTC 2012
Responsible-Changed-Why:
Over to maintain
Old Synopsis: /dev/tun stayes opened by PID after process is terminated
New Synopsis: [tun] tun(4) stays opened by PID after process is terminated
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Nov 8 23:43:39 UTC 2012
Responsibl
On 8 November 2012 13:48, Alexander V. Chernikov wrote:
>> That's a great catch! How'd you discover it?
>
> We have lots of FreeBSD routers doing 10G firewalling, so we're very much
> concerned with forwarding/firewalling performance, constantly looking for
> something to optimize :)
I mean, how
On 8 November 2012 06:34, Andre Oppermann wrote:
> TCP/UDP doesn't (want to) generate any fragments at all and tries
> to avoid it at almost all cost. We want to send very large packets
> and have the NIC fragment/segment it (TSO/UDP frag offload).
What about if it's a router and the frames don
On 08.11.2012 03:46, Adrian Chadd wrote:
On 7 November 2012 15:24, Alexander V. Chernikov wrote:
Hello list!
Currently we need to acquire 2 read locks to perform simple 6-byte copying
from arp record to packet ethernet header.
It seems that acquiring lle lock for fast path (main traffic flow)
On 08.11.2012 14:17, Andre Oppermann wrote:
On 07.11.2012 23:48, Alexander V. Chernikov wrote:
Hello list!
Currently size of arp/ndp hash is the following:
#define LLTBL_HASHTBL_SIZE 32 /* default 32 ? */
This may be OK for end hosts, but this is definitely not enough for
router howadays. Espe
Synopsis: icmp forward bandwithlimit
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: eadler
Responsible-Changed-When: Thu Nov 8 19:45:47 UTC 2012
Responsible-Changed-Why:
over to net
http://www.freebsd.org/cgi/query-pr.cgi?pr=173478
Old Synopsis: chown and chgrp operations fail between FreeBSD 9.1RC3 NFSv4
server and RH63 NFSv4 client
New Synopsis: [nfs] chown and chgrp operations fail between FreeBSD 9.1RC3
NFSv4 server and RH63 NFSv4 client
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: ead
Old Synopsis: RH63 NFSv4 client does not reconnect to FreeBSD 9.1RC3 NFSv4
server after server is rebooted
New Synopsis: [NFS] RH63 NFSv4 client does not reconnect to FreeBSD 9.1RC3
NFSv4 server after server is rebooted
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-B
The following reply was made to PR kern/156283; it has been noted by GNATS.
From: Ingo Flaschberger
To: bug-follo...@freebsd.org, i...@freebsd.org
Cc:
Subject: Re: kern/156283: [ip6] [patch] nd6_ns_input - rtalloc_mpath does
not return a locked rtentry
Date: Thu, 08 Nov 2012 17:55:11 +0100
W
On 08.11.2012 05:53, Adrian Chadd wrote:
On 7 November 2012 18:38, YongHyeon PYUN wrote:
On Wed, Nov 07, 2012 at 06:15:30PM -0800, Adrian Chadd wrote:
If so, may I suggest we perhaps accelerate discussing if_transmit() of
multiple frames per call?
Hmm, actually I'm still not a fan of if_tran
On 08.11.2012 03:38, YongHyeon PYUN wrote:
On Wed, Nov 07, 2012 at 06:15:30PM -0800, Adrian Chadd wrote:
If so, may I suggest we perhaps accelerate discussing if_transmit() of
multiple frames per call?
Hmm, actually I'm still not a fan of if_transmit() at this moment.
Honestly I don't have goo
On 08.11.2012 11:25, Alexander V. Chernikov wrote:
On 08.11.2012 14:24, Andre Oppermann wrote:
On 08.11.2012 00:24, Alexander V. Chernikov wrote:
Hello list!
Currently we need to acquire 2 read locks to perform simple 6-byte
copying from arp record to packet
ethernet header.
It seems that acq
On 08.11.2012 03:15, Adrian Chadd wrote:
So I am curious - did this give a real benefit?
No. Not really. The only place where it would have helped was with
locally sourced packets (from a socket) that are larger than the MTU.
For TCP we set the DF bit (don't fragment) so we get EMSGSIZE when
On 08.11.2012 14:24, Andre Oppermann wrote:
On 08.11.2012 00:24, Alexander V. Chernikov wrote:
Hello list!
Currently we need to acquire 2 read locks to perform simple 6-byte
copying from arp record to packet
ethernet header.
It seems that acquiring lle lock for fast path (main traffic flow) is
On 08.11.2012 00:24, Alexander V. Chernikov wrote:
Hello list!
Currently we need to acquire 2 read locks to perform simple 6-byte copying from
arp record to packet
ethernet header.
It seems that acquiring lle lock for fast path (main traffic flow) is not
necessary even with
current code.
My
On 07.11.2012 23:48, Alexander V. Chernikov wrote:
Hello list!
Currently size of arp/ndp hash is the following:
#defineLLTBL_HASHTBL_SIZE 32 /* default 32 ? */
This may be OK for end hosts, but this is definitely not enough for router
howadays. Especially
given that IPv6 hosts ge
22 matches
Mail list logo
