Re: MSI Wind Notebook's network interfaces
On Mon, Sep 08, 2008 at 12:32:42PM +0200, Milan Obuch wrote: > On Monday 08 September 2008 12:29:12 Pyun YongHyeon wrote: > > On Sat, Sep 06, 2008 at 08:03:52AM +0200, Milan Obuch wrote: > > > > [snip] > > > > > It was my pleasure and I would like to express my thanks for your great > > > work. If you will need in future some more testing with this hardware, > > > just drop me a line. Just a side note, will this patch be MFS'ed into > > > 7-STABLE in short timeframe? > > > > As soon as I get re's approval I'll commit to 7-stable. > > Thanks, I can wait a bit with this one. FYI: I've MFCed the fix to 7-stable(svn r183171). -- Regards, Pyun YongHyeon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Code release of ipfw NAT support for SCTP in FreeBSD-8
The Centre for Advanced Internet Architectures (CAIA http://caia.swin.edu.au) is proud to announce the release of alias_sctp version 0.2, an SCTP NAT patch to FreeBSD 8.x. Alias_sctp provides SCTP NAT functionality to the ipfw/ipfw_nat/libalias suite. Alias_sctp version 0.2 is a fully functional NAT for SCTP. It is part of the CAIA SONATA project (http://caia.swin.edu.au/urp/sonata). The code has been intentionally kept as separate as possible from the base modules to aid testing and debugging, and make it easier to port to other systems. We welcome and value feedback and comments. Please forward feedback to [EMAIL PROTECTED] and [EMAIL PROTECTED] Download patch from http://caia.swin.edu.au/urp/sonata/downloads.html Features of alias_sctp version 0.2: - Support for global multi-homing - Support for multi-homed privately addressed hosts using ASCONF modifications from the Internet Draft (R. Stewart and M. Tuexen, "Stream control transmission protocol (SCTP) network address translation", draft-stewart-behave-sctpnat-04, Jul. 2008) - Support for forwarding of T-flagged packets - Generation and delivery of AbortM/ErrorM packets upon detection of NAT collisions - Per-port forwarding rules - Dynamic configuration (via sysctl interface) of: o Logging and statistic gathering o Timer management o Hash Table sizes o Global address storage and other processing limits - Configuration via use of the "ipfw nat ... config" - Stateful SCTP association management. This project has been made possible in part by a grant from the Cisco University Research Program Fund at Community Foundation Silicon Valley. Jason -- -- Dr. Jason But Lecturer Telecommunications Engineering Academic Group Faculty of Information and Communication Technologies Swinburne University of Technology http://www.swinburne.edu.au/ict/telecommshome.htm ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Question regarding NFS
Hello, I am running an IPCop firewall for my entire network. I have a wireless network device on the blue subnet which must access a freebsd NFS server. In order to do this, I need to open a DMZ pinhole on a few select ports. It's my understanding that NFS chooses random ports and I was wondering if there was a way I could fix this. There is a good reason that the subnet for the wireless is separate from the wired and I'd rather not configure this thing over a VPN. The client connecting to the NFS server is a voyage computer (pretty much a small debian). Also, if at all possible, I'd like to keep performance reasonably high when large volumes of clients are connecting to the NFS server, I'm not sure if binding to one port may or may not make this impossible. I apologize for my stupidity and lack of understanding when it comes to NFS. Any help would be gladly appreciated, guys. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reading routing table
Bruce M. Simpson wrote: Debarshi Ray wrote: ... By the way, would you want someone to implement 'show' support for FreeBSD's route implementation? I can give it a go now. :-) For sure, we'd be very happy to see a patch like that. Many thanks BMS and don't forget the same patch for netsta\t so that it doesn't need /dev/kmem for netstat -r :-) BUT, don't forget about multiple routing tables.. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reading routing table
Debarshi Ray wrote: ... By the way, would you want someone to implement 'show' support for FreeBSD's route implementation? I can give it a go now. :-) For sure, we'd be very happy to see a patch like that. Many thanks BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What's the status of parallel netisr?
Jian Qiu wrote: Thanks again for the info. As you suggested, I did test on the most recent 7.0-stable-200807 kernel. The SMP throughout on the new kernel was improved to around 90MB/s. However, SMP kernel still had no advantage over UP, at least for this kind of single threaded applications. I further did the same test on Linux with both SMP and UP. I did observe the same trend. The throughput on UP (~210MB/ecs) was also much better than SMP (~170MB/sec). However, I was surprised again that the local UDP throughput on Linux was more than double of FreeBSD. Since all these tests were performed on the same machine, it must be because of the kernel that made such big differences. I'm curious what is the major performance bottleneck in FreeBSD network stack?? Is there any plan in community to address these issues? In our application-level tests FreeBSD significantly out-performs Linux, so either you have found a different workload, or something is not configured equally. One important thing I can think of off the top of my head is that Linux has a larger socket buffer size by default, so try tuning that on FreeBSD or confirm they are equal. If that still fails, can you provide test code? Kris ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What's the status of parallel netisr?
> Date: Thu, 18 Sep 2008 22:50:10 +0800 > From: "Jian Qiu" <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > Thanks again for the info. > > As you suggested, I did test on the most recent 7.0-stable-200807 kernel. > > The SMP throughout on the new kernel was improved to around 90MB/s. > > However, SMP kernel still had no advantage over UP, at least for this > kind of single threaded applications. > > I further did the same test on Linux with both SMP and UP. > > I did observe the same trend. > > The throughput on UP (~210MB/ecs) was also much better than SMP (~170MB/sec). > > However, I was surprised again that the local UDP throughput on Linux > was more than double of FreeBSD. > > Since all these tests were performed on the same machine, it must be > because of the kernel that made such big differences. > > I'm curious what is the major performance bottleneck in FreeBSD network > stack?? > > Is there any plan in community to address these issues? Did you try locking down the CPUs used with cpuset (FreeBSD) or taskset (Linux)? This can make a very substantial difference. Something like a UDP canon will run far more efficiently if locked to a single CPU and will run best if that CPU is not processing the interrupts. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgp5Hf429nPo6.pgp Description: PGP signature
Re: [PATCH] recvmsg() sendmsg() linux emulation
On Thu, Sep 18, 2008 at 06:31:11PM +0300, Kostik Belousov wrote: > On Thu, Sep 18, 2008 at 07:07:59PM +0400, Chagin Dmitry wrote: > > I still cannot answer to you, so be it. > > > On Thu, Sep 18, 2008 at 05:24:54PM +0300, Kostik Belousov wrote: > > > On Thu, Sep 18, 2008 at 05:57:36PM +0400, Chagin Dmitry wrote: > > > > diff --git a/src/sys/amd64/linux32/linux32_io.h > > > > b/src/sys/amd64/linux32/linux32_io.h > > > > new file mode 100644 > > > > index 000..c1a9f1c > > > > --- /dev/null > > > > +++ b/src/sys/amd64/linux32/linux32_io.h > > > > @@ -0,0 +1,47 @@ > > > > +/*- > > > > + * Copyright (c) 2004 Tim J. Robbins > > > > + * Copyright (c) 2001 Doug Rabson > > > > + * Copyright (c) 1994-1996 SЬren Schmidt > > > > + * All rights reserved. > > > ^^ Is this true ? > > > > > > > I have copied it from linux.h, can I remove it? > > No, you should specify yourself as the copyright holder. > ok > > > > > Coloring this further, do we need a new include file for one structure > > > and one function ? > > > > > > > You suggest to transfer it to linux.h? > > I can do it, but then it is necessary to insert #include > > into all files which include linux.h > > This may be a trouble. Is there any other compat/linux include that > requires uio ? yes, linux_util.h include uio now, but iovec32 stuff specific only for [EMAIL PROTECTED] emulation. -- Have fun! chd ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] recvmsg() sendmsg() linux emulation
On Thu, Sep 18, 2008 at 07:07:59PM +0400, Chagin Dmitry wrote: I still cannot answer to you, so be it. > On Thu, Sep 18, 2008 at 05:24:54PM +0300, Kostik Belousov wrote: > > On Thu, Sep 18, 2008 at 05:57:36PM +0400, Chagin Dmitry wrote: > > > diff --git a/src/sys/amd64/linux32/linux32_io.h > > > b/src/sys/amd64/linux32/linux32_io.h > > > new file mode 100644 > > > index 000..c1a9f1c > > > --- /dev/null > > > +++ b/src/sys/amd64/linux32/linux32_io.h > > > @@ -0,0 +1,47 @@ > > > +/*- > > > + * Copyright (c) 2004 Tim J. Robbins > > > + * Copyright (c) 2001 Doug Rabson > > > + * Copyright (c) 1994-1996 SЬren Schmidt > > > + * All rights reserved. > > ^^ Is this true ? > > > > I have copied it from linux.h, can I remove it? No, you should specify yourself as the copyright holder. > > > Coloring this further, do we need a new include file for one structure > > and one function ? > > > > You suggest to transfer it to linux.h? > I can do it, but then it is necessary to insert #include > into all files which include linux.h This may be a trouble. Is there any other compat/linux include that requires uio ? pgp10Vx1shEEb.pgp Description: PGP signature
Re: [PATCH] recvmsg() sendmsg() linux emulation
On Thu, Sep 18, 2008 at 05:24:54PM +0300, Kostik Belousov wrote: > On Thu, Sep 18, 2008 at 05:57:36PM +0400, Chagin Dmitry wrote: > > diff --git a/src/sys/amd64/linux32/linux32_io.h > > b/src/sys/amd64/linux32/linux32_io.h > > new file mode 100644 > > index 000..c1a9f1c > > --- /dev/null > > +++ b/src/sys/amd64/linux32/linux32_io.h > > @@ -0,0 +1,47 @@ > > +/*- > > + * Copyright (c) 2004 Tim J. Robbins > > + * Copyright (c) 2001 Doug Rabson > > + * Copyright (c) 1994-1996 SЬren Schmidt > > + * All rights reserved. > ^^ Is this true ? > I have copied it from linux.h, can I remove it? > Coloring this further, do we need a new include file for one structure > and one function ? > You suggest to transfer it to linux.h? I can do it, but then it is necessary to insert #include into all files which include linux.h thnx! -- Have fun! chd ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What's the status of parallel netisr?
Thanks again for the info. As you suggested, I did test on the most recent 7.0-stable-200807 kernel. The SMP throughout on the new kernel was improved to around 90MB/s. However, SMP kernel still had no advantage over UP, at least for this kind of single threaded applications. I further did the same test on Linux with both SMP and UP. I did observe the same trend. The throughput on UP (~210MB/ecs) was also much better than SMP (~170MB/sec). However, I was surprised again that the local UDP throughput on Linux was more than double of FreeBSD. Since all these tests were performed on the same machine, it must be because of the kernel that made such big differences. I'm curious what is the major performance bottleneck in FreeBSD network stack?? Is there any plan in community to address these issues? Many thanks. Jian On Wed, Sep 17, 2008 at 3:27 AM, Kris Kennaway <[EMAIL PROTECTED]> wrote: > Jian Qiu wrote: >> >> Interesting. >> >> I did a test on local UDP throughput. >> >> I was surprised to find out the performance with a SMP kernel was >> worse than UP. (~74MB/s v.s. 96 MB/s). >> >> I had though parallel netisr might be a solution. > > Make sure you are testing with either 8.0 or 7.1 (or late 7.0-STABLE), i.e. > after the fixes to improve UDP performance on SMP systems. > > Kris > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] recvmsg() sendmsg() linux emulation
On Thu, Sep 18, 2008 at 05:57:36PM +0400, Chagin Dmitry wrote: > diff --git a/src/sys/amd64/linux32/linux32_io.h > b/src/sys/amd64/linux32/linux32_io.h > new file mode 100644 > index 000..c1a9f1c > --- /dev/null > +++ b/src/sys/amd64/linux32/linux32_io.h > @@ -0,0 +1,47 @@ > +/*- > + * Copyright (c) 2004 Tim J. Robbins > + * Copyright (c) 2001 Doug Rabson > + * Copyright (c) 1994-1996 SЬren Schmidt > + * All rights reserved. ^^ Is this true ? Coloring this further, do we need a new include file for one structure and one function ? P.S. Your MUA sets Mail-Followup-To: to the full list of the recipients _except_ you. Is this intentional ? pgpkYBYig8Fpn.pgp Description: PGP signature
Re: [PATCH] recvmsg() sendmsg() linux emulation
On Thu, Sep 18, 2008 at 09:38:31AM +0200, Alexander Leidinger wrote:
> Quoting "Chagin Dmitry" <[EMAIL PROTECTED]> (from Wed, 17 Sep 2008
> 23:02:30 +0400):
>
> >On Wed, Sep 17, 2008 at 10:38:01PM +0400, Chagin Dmitry wrote:
> >>
> >>Please review, any comment will be helpful.
>
> I did just a very quick look...
>
> >@@ -978,9 +1072,13 @@ linux_sendmsg(struct thread *td, struct
> >linux_sendmsg_args *args)
> > */
> > if (msg.msg_control != NULL && msg.msg_controllen == 0)
> > msg.msg_control = NULL;
> >+
> >+#if defined(__amd64__) && defined(COMPAT_LINUX32)
> >+error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen,
> >+&iov, EMSGSIZE);
> >+#else
> > error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE);
> >-if (error)
> >-return (error);
> >+#endif
> > msg.msg_iov = iov;
> > msg.msg_flags = 0;
> > error = linux_sendit(td, args->s, &msg, args->flags, UIO_USERSPACE);
>
> You've lost the error handling in the conditional.
>
It's accepted, thnx!
diff --git a/src/sys/amd64/linux32/linux.h b/src/sys/amd64/linux32/linux.h
index 8940289..9439900 100644
--- a/src/sys/amd64/linux32/linux.h
+++ b/src/sys/amd64/linux32/linux.h
@@ -685,6 +685,7 @@ union l_semun {
#defineLINUX_SO_NO_CHECK 11
#defineLINUX_SO_PRIORITY 12
#defineLINUX_SO_LINGER 13
+#defineLINUX_SO_PASSCRED 16
#defineLINUX_SO_PEERCRED 17
#defineLINUX_SO_RCVLOWAT 18
#defineLINUX_SO_SNDLOWAT 19
@@ -709,6 +710,28 @@ struct l_sockaddr {
charsa_data[14];
} __packed;
+struct l_msghdr {
+ l_uintptr_t msg_name;
+ l_int msg_namelen;
+ l_uintptr_t msg_iov;
+ l_size_tmsg_iovlen;
+ l_uintptr_t msg_control;
+ l_size_tmsg_controllen;
+ l_uint msg_flags;
+} __packed;
+
+struct l_cmsghdr {
+ l_size_tcmsg_len;
+ l_int cmsg_level;
+ l_int cmsg_type;
+} __packed;
+
+struct l_ucred {
+ uint32_tpid;
+ uint32_tuid;
+ uint32_tgid;
+} __packed;
+
struct l_ifmap {
l_ulong mem_start;
l_ulong mem_end;
diff --git a/src/sys/amd64/linux32/linux32_io.h
b/src/sys/amd64/linux32/linux32_io.h
new file mode 100644
index 000..c1a9f1c
--- /dev/null
+++ b/src/sys/amd64/linux32/linux32_io.h
@@ -0,0 +1,47 @@
+/*-
+ * Copyright (c) 2004 Tim J. Robbins
+ * Copyright (c) 2001 Doug Rabson
+ * Copyright (c) 1994-1996 SЬren Schmidt
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer
+ *in this position and unchanged.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote products
+ *derived from this software without specific prior written permission
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * $FreeBSD$
+ */
+
+#ifndef _AMD64_LINUX32_IO_H_
+#define_AMD64_LINUX32_IO_H_
+
+
+struct iovec32 {
+ u_int32_t iov_base;
+ int iov_len;
+};
+
+CTASSERT(sizeof(struct iovec32) == 8);
+
+int linux32_copyiniov(struct iovec32 *iovp32, u_int iovcnt, struct iovec
**iovp,
+int error);
+
+#endif /* !_AMD64_LINUX32_IO_H_ */
diff --git a/src/sys/amd64/linux32/linux32_machdep.c
b/src/sys/amd64/linux32/linux32_machdep.c
index 32cbe0b..26459c9 100644
--- a/src/sys/amd64/linux32/linux32_machdep.c
+++ b/src/sys/amd64/linux32/linux32_machdep.c
@@ -65,6 +65,7 @@ __FBSDID("$FreeBSD: src/sys/amd64/linux32/linux32_machdep.c,v
1.49 2008/09/08 09
#include
#include
+#include
#include
#include
#include
@@ -232,13 +233,6 @@ linux_execve(struct thread *td, struct linux_execve_args
*args)
return (error);
}
-struct iovec32 {
- u_int32_t
Re: reading routing table
So I got something working for FreeBSD now: http://rishi.fedorapeople.org/gnu/inetutils-1.5.tar.gz I have been using a combination of sysctl and PF_ROUTE to retrieve the routing table, much like the approach taken by the NetBSD implementation. Support for modifying the routing table is yet to be implemented. Thanks for all your comments. By the way, would you want someone to implement 'show' support for FreeBSD's route implementation? I can give it a go now. :-) Happy hacking, Debarshi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] recvmsg() sendmsg() linux emulation
Quoting "Chagin Dmitry" <[EMAIL PROTECTED]> (from Wed, 17 Sep 2008 23:02:30 +0400): On Wed, Sep 17, 2008 at 10:38:01PM +0400, Chagin Dmitry wrote: Please review, any comment will be helpful. I did just a very quick look... @@ -978,9 +1072,13 @@ linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args) */ if (msg.msg_control != NULL && msg.msg_controllen == 0) msg.msg_control = NULL; + +#if defined(__amd64__) && defined(COMPAT_LINUX32) + error = linux32_copyiniov(PTRIN(msg.msg_iov), msg.msg_iovlen, + &iov, EMSGSIZE); +#else error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE); - if (error) - return (error); +#endif msg.msg_iov = iov; msg.msg_flags = 0; error = linux_sendit(td, args->s, &msg, args->flags, UIO_USERSPACE); You've lost the error handling in the conditional. Bye, Alexander. -- BOFH excuse #266: All of the packets are empty http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
