Re: RFC: TSO patch for current
Jack Vogel wrote: This is a patch for the stack and the em driver to enable TSO on CURRENT. Previously I had problems getting it to work, but this is functional. I should note that CURRENT is being a pain right now, when I comment out em in the config the kernel panics coming up, so I had to substitute this code into the tree. Rather bizarre :) I have this functionality running on a 6.1 based system, and our test group is already testing against that driver, so far things are looking good. I have designed it so the driver can continue to be built without support. There is also a sysctl in the stack code so you can set net.inet.tcp.tso_enable on or off and compare. I know there may be some refinements to add in, but I would like to get this into CURRENT as a start. I can't comment on the em part but the tcp_output.c stuff looks very much like a straight port from NetBSD. If we take code from the other BSDs we have to remark this in the emails we send with patches and the commit message (otherwise we get accused of 'stealing without attribution'). Although the code would work I have some ideas to implement this in a different way for our stack (we have certain divergence from the other BSDs). If you don't get an alternative patch form me until this Thursday be free to go with this patch taking into consideration Robert's comments and mine from your earlier version. -- Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem with uipc_mbuf.c
Maxim Konovalov wrote:
On Tue, 29 Aug 2006, 17:15+0200, Andre Oppermann wrote:
John-Mark Gurney wrote:
Randall Stewart wrote this message on Mon, Aug 28, 2006 at 17:04 -0400:
atomic_fetchadd_int(m->m_ext.ref_cnt, -1) == 0) {
^
This should be 1 not 0.. as apparently fetchadd_int returns the
old value (at least that's what atomic(9) says), which means that
if we ever race on this comparision, we won't free though we
should of...
if we look at refcount.h, it does:
return (atomic_fetchadd_int(count, -1) == 1);
which release a reference and apparently returns true if it needs to
be free'd...
Though the wierd part is that andre, "fixed" it to be 0 in 1.157:
Fix a logic error introduced with mandatory mbuf cluster
refcounting and freeing of mbufs+clusters back to the packet zone.
Honestly I'm a bit confused myself now and have to dig up things from
when I did the change. However I'm certain there was a problem and the
commit fixed it in some way (not necessarily the correct way). Before
the 'fix' there were some larger leaks going on.
So what's the conclusion? Perhaps it's worth to add an XXX comment in
meantime.
Please give me until Thursday to resolve this issue.
--
Andre
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/102035: [plip] plip networking disables parallel port printing
The following reply was made to PR kern/102035; it has been noted by GNATS. From: George Mitchell <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: kern/102035: [plip] plip networking disables parallel port printing Date: Sat, 2 Sep 2006 10:35:32 -0700 (PDT) Here is a corrected patch for this problem. In a default installation with IPv6 enabled, there will be attempts by both IPv4 and IPv6 to bring up plip[012]. The patch to rc.d/network_ipv6 detects when ipv6_ifconfig_plipn is set to NOAUTO. The patch to defaults/rc.conf sets both ifconfig_plip[012] and ipv6_ifconfig_plip[012] to NOAUTO, keeping the plip interfaces from being brought UP automatically. --- etc/defaults/rc.conf.orig Sat May 6 21:00:25 2006 +++ etc/defaults/rc.confSat Sep 2 10:29:53 2006 @@ -158,6 +158,10 @@ cloned_interfaces="" # List of cloned network interfaces to create. #cloned_interfaces="gif0 gif1 gif2 gif3" # Pre-cloning GENERIC config. ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. +# Average user does not want to start networking on plip[012]. +ifconfig_plip0="NOAUTO" +ifconfig_plip1="NOAUTO" +ifconfig_plip2="NOAUTO" #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0x" # Sample alias entry ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/102035: [plip] plip networking disables parallel port printing
The following reply was made to PR kern/102035; it has been noted by GNATS. From: George Mitchell <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: kern/102035: [plip] plip networking disables parallel port printing Date: Sat, 2 Sep 2006 10:36:22 -0700 (PDT) Here is a corrected patch for this problem. In a default installation with IPv6 enabled, there will be attempts by both IPv4 and IPv6 to bring up plip[012]. The patch to rc.d/network_ipv6 detects when ipv6_ifconfig_plipn is set to NOAUTO. The patch to defaults/rc.conf sets both ifconfig_plip[012] and ipv6_ifconfig_plip[012] to NOAUTO, keeping the plip interfaces from being brought UP automatically. --- etc/defaults/rc.conf.orig Sat May 6 21:00:25 2006 +++ etc/defaults/rc.confSat Sep 2 10:29:53 2006 @@ -158,6 +158,10 @@ cloned_interfaces="" # List of cloned network interfaces to create. #cloned_interfaces="gif0 gif1 gif2 gif3" # Pre-cloning GENERIC config. ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration. +# Average user does not want to start networking on plip[012]. +ifconfig_plip0="NOAUTO" +ifconfig_plip1="NOAUTO" +ifconfig_plip2="NOAUTO" #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0x" # Sample alias entry ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/102035: [plip] plip networking disables parallel port printing
The following reply was made to PR kern/102035; it has been noted by GNATS.
From: George Mitchell <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: kern/102035: [plip] plip networking disables parallel port printing
Date: Sat, 2 Sep 2006 10:38:10 -0700 (PDT)
Here is a corrected patch for this problem. In a default installation
with IPv6 enabled, there will be attempts by both IPv4 and IPv6 to
bring up plip[012]. The patch to rc.d/network_ipv6 detects when
ipv6_ifconfig_plipn is set to NOAUTO. The patch to defaults/rc.conf
sets both ifconfig_plip[012] and ipv6_ifconfig_plip[012] to NOAUTO,
keeping the plip interfaces from being brought UP automatically.
--- etc/defaults/rc.conf.orig Sat May 6 21:00:25 2006
+++ etc/defaults/rc.confSat Sep 2 10:29:53 2006
@@ -158,6 +158,10 @@
cloned_interfaces="" # List of cloned network interfaces to create.
#cloned_interfaces="gif0 gif1 gif2 gif3" # Pre-cloning GENERIC config.
ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration.
+# Average user does not want to start networking on plip[012].
+ifconfig_plip0="NOAUTO"
+ifconfig_plip1="NOAUTO"
+ifconfig_plip2="NOAUTO"
#ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0x" # Sample alias
entry
.
#ifconfig_ed0_ipx="ipx 0x00010010" # Sample IPX address family entry.
#ifconfig_fxp0_name="net0" # Change interface name from fxp0 to net0.
@@ -358,6 +362,10 @@
#ipv6_prefix_ep0="fec0:::0003 fec0:::0004" # Examples for
rtr.
#ipv6_ifconfig_ed0="fec0:0:0:5::1 prefixlen 64"# Sample manual assign
e
ntry
#ipv6_ifconfig_ed0_alias0="fec0:0:0:5::2 prefixlen 64" # Sample alias entry.
+# Average user does not want to start networking on plip[012].
+ipv6_ifconfig_plip0="NOAUTO"
+ipv6_ifconfig_plip1="NOAUTO"
+ipv6_ifconfig_plip2="NOAUTO"
ipv6_default_interface="NO"# Default output interface for scoped addrs.
# Now this works only for IPv6 link local
# multicast addrs.
--- etc/rc.d/network_ipv6.orig Sat May 6 21:00:26 2006
+++ etc/rc.d/network_ipv6 Sat Sep 2 10:13:21 2006
@@ -47,8 +47,19 @@
case ${ipv6_network_interfaces} in
[Aa][Uu][Tt][Oo])
- # Get a list of network interfaces
- ipv6_network_interfaces="`ifconfig -l`"
+ # Get a list of network interfaces, minus the NOAUTO ones
+ ipv6_network_interfaces=''
+ _args="`ifconfig -l`"
+ for i in $_args; do
+ eval _arg=\$ipv6_ifconfig_$i
+ case $_arg in
+ [Nn][Oo][Aa][Uu][Tt][Oo])
+ ;;
+ *)
+
ipv6_network_interfaces="$ipv6_network_interface
s $i"
+ ;;
+ esac
+ done
;;
[Nn][Oo][Nn][Ee])
ipv6_network_interfaces=''
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/102607: [if_bridge] don't generate random L2 address
The following reply was made to PR kern/102607; it has been noted by GNATS. From: Stefan Bethke <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: kern/102607: [if_bridge] don't generate random L2 address Date: Sun, 3 Sep 2006 01:09:16 +0200 Here's my suggestion for an addition to if_bridge(4): --- if_bridge.4.origSun Aug 13 20:44:18 2006 +++ if_bridge.4 Fri Sep 1 18:53:19 2006 @@ -107,6 +107,13 @@ in .Xr rc.conf 5 . .Pp +The +.Nm +interface randomly chooses a link (MAC) address in the range reserved for +locally adminstered addresses when it is created. +The address can be changed by assigning the desired link address using +.Xr ifconfig 8 . +.Pp The MTU of the first member interface to be added is used as the bridge MTU. All additional members are required to have exactly the same value. .Pp @@ -231,6 +238,16 @@ addm fxp6 stp fxp6 \e addm fxp7 stp fxp7 \e up +.Ed +.Pp +The bridge can be used as a regular host interface at the same time as +bridging between it's member ports. In this example, the bridge connects em0 +and em1, and will receive it's IP address through DHCP: +.Bd -literal -offset indent +cloned_interfaces="bridge0" +ifconfig_bridge0="link 12:34:56:78:9a:bc addm em0 addm em0 DHCP" +ifconfig_em0="up" +ifconfig_em1="up" .Ed .Pp The bridge can tunnel Ethernet across an IP internet using the EtherIP ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: TSO patch for current
On 9/2/06, Andre Oppermann <[EMAIL PROTECTED]> wrote: Jack Vogel wrote: > This is a patch for the stack and the em driver to enable TSO > on CURRENT. Previously I had problems getting it to work, but > this is functional. > > I should note that CURRENT is being a pain right now, when > I comment out em in the config the kernel panics coming up, > so I had to substitute this code into the tree. Rather bizarre :) > > I have this functionality running on a 6.1 based system, and > our test group is already testing against that driver, so far > things are looking good. > > I have designed it so the driver can continue to be built > without support. There is also a sysctl in the stack code > so you can set net.inet.tcp.tso_enable on or off and > compare. > > I know there may be some refinements to add in, but I > would like to get this into CURRENT as a start. I can't comment on the em part but the tcp_output.c stuff looks very much like a straight port from NetBSD. If we take code from the other BSDs we have to remark this in the emails we send with patches and the commit message (otherwise we get accused of 'stealing without attribution'). Although the code would work I have some ideas to implement this in a different way for our stack (we have certain divergence from the other BSDs). If you don't get an alternative patch form me until this Thursday be free to go with this patch taking into consideration Robert's comments and mine from your earlier version. Yes, I was planning on adding the code Robert talked about, it doesnt change anything fundamental in this patch. What I would like to see in some ways is an idea from what Linux does, but it would change the stack more than this does. We would remove all code that segments from tcp and do it just before calling the driver, in effect the routine Robert is talking about would be the normal path, doing software segmentation, and at that same point we would discover that the interface was TSO capable and call that. I think at that point we would have easy access to the ifp struct and it would eliminate the need for the discovery routine in tcp_subr.c. What were you thinking of doing? Cheers, Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: TSO patch for current
On 9/2/06, Andre Oppermann <[EMAIL PROTECTED]> wrote: I can't comment on the em part but the tcp_output.c stuff looks very much like a straight port from NetBSD. If we take code from the other BSDs we have to remark this in the emails we send with patches and the commit message (otherwise we get accused of 'stealing without attribution'). I dont know that I'd call it a straight port, rather I was working from some prototype code that Prafulla had working back on 4.7, but I think at that time that he may have patterned it after NetBSD. I certainly don't claim any grand originality here, we stop the tcp stack from segmenting so the hardware can do it :), but I have no problem attributing the NetBSD crew. Cheers, Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/102035: [plip] plip networking disables parallel port printing
The following reply was made to PR kern/102035; it has been noted by GNATS.
From: George Mitchell <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: kern/102035: [plip] plip networking disables parallel port printing
Date: Sat, 2 Sep 2006 19:12:18 -0700 (PDT)
My apologies for the multiple screwed-up mailings of this patch! Here is the
proper patch correctly formatted.
Here is a corrected patch for this problem. In a default installation
with IPv6 enabled, there will be attempts by both IPv4 and IPv6 to
bring up plip[012]. The patch to rc.d/network_ipv6 detects when
ipv6_ifconfig_plipn is set to NOAUTO. The patch to defaults/rc.conf
sets both ifconfig_plip[012] and ipv6_ifconfig_plip[012] to NOAUTO,
keeping the plip interfaces from being brought UP automatically.
--- etc/defaults/rc.conf.orig Sat May 6 21:00:25 2006
+++ etc/defaults/rc.conf Sat Sep 2 10:29:53 2006
@@ -158,6 +158,10 @@
cloned_interfaces="" # List of cloned network interfaces to create.
#cloned_interfaces="gif0 gif1 gif2 gif3" # Pre-cloning GENERIC config.
ifconfig_lo0="inet 127.0.0.1" # default loopback device configuration.
+# Average user does not want to start networking on plip[012].
+ifconfig_plip0="NOAUTO"
+ifconfig_plip1="NOAUTO"
+ifconfig_plip2="NOAUTO"
#ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0x" # Sample alias
entry.
#ifconfig_ed0_ipx="ipx 0x00010010"# Sample IPX address family entry.
#ifconfig_fxp0_name="net0"# Change interface name from fxp0 to net0.
@@ -358,6 +362,10 @@
#ipv6_prefix_ep0="fec0:::0003 fec0:::0004" # Examples for
rtr.
#ipv6_ifconfig_ed0="fec0:0:0:5::1 prefixlen 64" # Sample manual assign
entry
#ipv6_ifconfig_ed0_alias0="fec0:0:0:5::2 prefixlen 64" # Sample alias entry.
+# Average user does not want to start networking on plip[012].
+ipv6_ifconfig_plip0="NOAUTO"
+ipv6_ifconfig_plip!="NOAUTO"
+ipv6_ifconfig_plip2="NOAUTO"
ipv6_default_interface="NO" # Default output interface for scoped addrs.
# Now this works only for IPv6 link local
# multicast addrs.
--- etc/rc.d/network_ipv6.orig Sat May 6 21:00:26 2006
+++ etc/rc.d/network_ipv6 Sat Sep 2 10:13:21 2006
@@ -47,8 +47,19 @@
case ${ipv6_network_interfaces} in
[Aa][Uu][Tt][Oo])
- # Get a list of network interfaces
- ipv6_network_interfaces="`ifconfig -l`"
+ # Get a list of network interfaces, minus the NOAUTO ones
+ ipv6_network_interfaces=''
+ _args="`ifconfig -l`"
+ for i in $_args; do
+ eval _arg=\$ipv6_ifconfig_$i
+ case $_arg in
+ [Nn][Oo][Aa][Uu][Tt][Oo])
+ ;;
+ *)
+
ipv6_network_interfaces="$ipv6_network_interfaces $i"
+ ;;
+ esac
+ done
;;
[Nn][Oo][Nn][Ee])
ipv6_network_interfaces=''
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
How to use ng_atmllc(4).
I am sometime using the environment IEEE802.1a SNAP on ethernet. But FreeBSD's network stack supports only EtherframeII as IP. So I researched how to use on IEEE802.1a SNAP. I think that following approch is good. But I couldn't do it:-(. # ngctl mkpeer . eiface if_ngeth ether # ngctl mkpeer . atmllc . ether (Does not create a node) # ngctl list There are 5 total nodes: Name: ngctl61978 Type: socket ID: 00be Num hooks: 0 Name: ngeth0 Type: ether ID: 00ae Num hooks: 0 Name:Type: eiface ID: 00ad Num hooks: 0 Name: iwi0Type: ether ID: 0002 Num hooks: 0 Name: rl0 Type: ether ID: 0001 Num hooks: 0 | +++ | ngeth0 | +++ | EtherframeII +++ |ng_atmllc| +++ | IEEE802.1a SNAP +++ | rl0 | +++ | Sorry, I cannot draw above network graph like 'ngctl dot' stlye. So I don't know that above graph is whether OK or NG. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to use ng_atmllc(4).
On Sun, 3 Sep 2006 13:20:50 +0900 Norikatsu Shigemura <[EMAIL PROTECTED]> wrote: > I am sometime using the environment IEEE802.1a SNAP on ethernet. > But FreeBSD's network stack supports only EtherframeII as IP. So > I researched how to use on IEEE802.1a SNAP. I think that following > approch is good. But I couldn't do it:-(. > # ngctl mkpeer . eiface if_ngeth ether > # ngctl mkpeer . atmllc . ether (Does not create a node) > # ngctl list > There are 5 total nodes: > Name: ngctl61978 Type: socket ID: 00be Num hooks: > 0 > Name: ngeth0 Type: ether ID: 00ae Num hooks: > 0 > Name:Type: eiface ID: 00ad Num hooks: > 0 > Name: iwi0Type: ether ID: 0002 Num hooks: > 0 > Name: rl0 Type: ether ID: 0001 Num hooks: > 0 Oops, I missed. I'm testing until following level. # ngctl mkpeer . eiface if_ngeth ether # ngctl mkpeer ngeth0: atmllc lower ether # ngctl list There are 6 total nodes: Name: ngctl1269 Type: socket ID: 000f Num hooks: 0 Name:Type: atmllc ID: 000a Num hooks: 1 Name: ngeth0 Type: ether ID: 0007 Num hooks: 1 Name:Type: eiface ID: 0006 Num hooks: 0 Name: iwi0Type: ether ID: 0003 Num hooks: 0 Name: rl0 Type: ether ID: 0002 Num hooks: 0 I have no idea to connect ngeth0 <-> rl0. >| > +++ > | ngeth0 | > +++ >| EtherframeII > +++ > |ng_atmllc| > +++ >| IEEE802.1a SNAP > +++ > | rl0 | > +++ >| > > Sorry, I cannot draw above network graph like 'ngctl dot' stlye. > So I don't know that above graph is whether OK or NG. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/102035: [plip] plip networking disables parallel port printing
Your approach is interesting, but I'm not sure I like the idea of adding a new semantic to the defaults file. Would you consider instead modifying network6_interface_setup in network.subr to not automatically configure a plip interface if ipv6_ifconfig_plipN is unset or null? That would accomplish the same thing, but it would be behind the scenes. Doug -- This .signature sanitized for your protection ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
