Re: [PATCH] Add a new TCP_IGNOREIDLE socket option
On Wed, Feb 20, 2013 at 11:59 AM, Lawrence Stewart wrote: > Hi Sephe, > > On 02/20/13 13:37, Sepherosa Ziehau wrote: >> On Wed, Feb 20, 2013 at 9:46 AM, Lawrence Stewart >> wrote: >>> *crickets chirping* >>> >>> Time to move this discussion forward... >>> >>> >>> If any robust counter-arguments exist, now is the time for us to hear >>> them. I haven't read anything thus far which convinces me that we should >>> not provide knobs to tune our stack's dynamics. >>> >>> In the absence of any compelling counter-arguments, I would like to >>> propose the following: >>> >>> - We rename the net.inet.tcp.experimental sysctl node introduced in >>> r242266 for IW10 support to net.inet.tcp.nonstandard, and re-parent the >>> initcwnd10 sysctl under this node. > > I should also add that I think initcwnd10 should be changed to initcwnd > and take the number of segments as a value. Yeah, I would suggest the same. > >>> - We introduce a new net.inet.tcp.nonstandard.allowed sysctl variable >>> and default it to 0. Only when it is changed to 1 will we allow starkly >>> non standards compliant behaviour to be enabled in the stack. As a more >>> complex but expressive alternative, we can make the sysctl take a bit >>> mask or CSV string which specifies which non-standard options the sys >>> admin permits (I'd prefer this as we can easily test non-standard >>> options like IW10 in head without blanket enabling all non standard >>> behaviour). > > To be clear, my proposal is that specifying an allowed option in > net.inet.tcp.nonstandard.allowed would not enable it as the default on > all connections, but would allow the per-application mechanism we define > to set the option. Setting net.inet.tcp.nonstandard.option_x to 1 would > enable the option as default for all connections. > >>> - We introduce a new net.inet.tcp.nonstandard.noidlereset sysctl >>> variable, and use it to enable/disable window-reset-after-idle behaviour >>> as proposed by John. >>> >>> - We don't introduce a TF_IGNOREIDLE sockopt, and instead introduce a >>> more generic sockopt and/or mechanism for per-application tuning of all >>> options which affect stack dynamics (both standard and non-standard >>> options). I'm open to suggestions on what this could/should look like. >> >> Lawrence, >> >> A route metric? BTW, as for IW10, it could also become a route metric >> (as proposed by the draft author's presentation >> http://www.ietf.org/proceedings/79/slides/tcpm-0.pdf) > > Are you suggesting having the ability to set knobs as route metrics in > addition to sysctl and a per-app mechanism? If so then I am very much in > favour of this. Assuming an option has been allowed in > net.inet.tcp.nonstandard.allowed, it should be able to be set by an > application or on a route, perhaps with a precedence hierarchy of app > request trumps route metric trumps system default setting? I suggest using route metrics in addition to the global sysctls; route metrics take precedence over global sysctls. I don't object the per-socket settings though. However, IMHO, these options (IW10 and ignoring idle restart, and probably others) are administrative, so applications probably should not mess with them. Best Regards, sephe -- Tomorrow Will Never Die ___ 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"
Re: point-to-point network with unknown peer ip address
On 2013-Feb-20 02:56:55 -0800, "M. V." wrote: >I have 2 FreeBSD8.2 systems. I have a point-to-point interface >(myif0) on each side connected together, but on each side I don't >know IP address of the other side. to make the connection work, On >each side I set IP address (2.2.2.32/24 and 2.2.2.33/24) and added a >route which sends all traffic to the network to interface: > >#route add 2.2.2.0/24 -interface myif0 > >#ifconfig myif0 >myif0: flags=89d1 >metric 0 mtu 1500 I'm not certain what you are trying to achieve but point-to-point links would normally be /32, not /24. >now, from one side if I ping the other side (say 2.2.2.33/24) >everything seems ok. but if I ping any other IP in the network (say >2.2.2.100/24) the other endpoint sends back packet + an ICMP REDIRECT >packet. 2.2.2.100 is not a valid address in the network you have described. Where did you expect you expect the packet to be sent? >my sysctl output: >... > >net.inet.ip.redirect: 1 >net.inet.icmp.drop_redirect: 0 >... You don't say what you are trying to achieve but my crystal ball says that you want net.inet.ip.forwarding=1 on the remote system. -- Peter Jeremy pgp4c2p5tAMBd.pgp Description: PGP signature
Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type
The following reply was made to PR kern/172113; it has been noted by GNATS. From: John Baldwin To: bug-follo...@freebsd.org, egrosb...@rdtc.ru Cc: Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type Date: Thu, 21 Feb 2013 17:12:55 -0500 An update on this. I think we should just use a workaround as this seems to be specific to a certain set of motherboards. This is the fix I'm using locally: Index: if_igb.c === --- if_igb.c(revision 243732) +++ if_igb.c(working copy) @@ -1522,6 +1522,15 @@ u32 newitr = 0; boolmore_rx; + /* +* The onboard adapters on certain SuperMicro X8* boards +* trigger a spurious interrupt during boot. Since it +* occurs before the interface is fully configured it +* triggers a panic. Ignore the interrupt instead. +*/ + if (!(adapter->ifp->if_drv_flags & IFF_DRV_RUNNING)) + return; + E1000_WRITE_REG(&adapter->hw, E1000_EIMC, que->eims); ++que->irqs; -- John Baldwin ___ 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"
Re: [PATCH] Add a new TCP_IGNOREIDLE socket option
On 02/21/13 20:20, Sepherosa Ziehau wrote: > On Wed, Feb 20, 2013 at 11:59 AM, Lawrence Stewart > wrote: >> Hi Sephe, >> >> On 02/20/13 13:37, Sepherosa Ziehau wrote: >>> On Wed, Feb 20, 2013 at 9:46 AM, Lawrence Stewart >>> wrote: *crickets chirping* Time to move this discussion forward... If any robust counter-arguments exist, now is the time for us to hear them. I haven't read anything thus far which convinces me that we should not provide knobs to tune our stack's dynamics. In the absence of any compelling counter-arguments, I would like to propose the following: - We rename the net.inet.tcp.experimental sysctl node introduced in r242266 for IW10 support to net.inet.tcp.nonstandard, and re-parent the initcwnd10 sysctl under this node. >> >> I should also add that I think initcwnd10 should be changed to initcwnd >> and take the number of segments as a value. > > Yeah, I would suggest the same. > >> - We introduce a new net.inet.tcp.nonstandard.allowed sysctl variable and default it to 0. Only when it is changed to 1 will we allow starkly non standards compliant behaviour to be enabled in the stack. As a more complex but expressive alternative, we can make the sysctl take a bit mask or CSV string which specifies which non-standard options the sys admin permits (I'd prefer this as we can easily test non-standard options like IW10 in head without blanket enabling all non standard behaviour). >> >> To be clear, my proposal is that specifying an allowed option in >> net.inet.tcp.nonstandard.allowed would not enable it as the default on >> all connections, but would allow the per-application mechanism we define >> to set the option. Setting net.inet.tcp.nonstandard.option_x to 1 would >> enable the option as default for all connections. >> - We introduce a new net.inet.tcp.nonstandard.noidlereset sysctl variable, and use it to enable/disable window-reset-after-idle behaviour as proposed by John. - We don't introduce a TF_IGNOREIDLE sockopt, and instead introduce a more generic sockopt and/or mechanism for per-application tuning of all options which affect stack dynamics (both standard and non-standard options). I'm open to suggestions on what this could/should look like. >>> >>> Lawrence, >>> >>> A route metric? BTW, as for IW10, it could also become a route metric >>> (as proposed by the draft author's presentation >>> http://www.ietf.org/proceedings/79/slides/tcpm-0.pdf) >> >> Are you suggesting having the ability to set knobs as route metrics in >> addition to sysctl and a per-app mechanism? If so then I am very much in >> favour of this. Assuming an option has been allowed in >> net.inet.tcp.nonstandard.allowed, it should be able to be set by an >> application or on a route, perhaps with a precedence hierarchy of app >> request trumps route metric trumps system default setting? > > I suggest using route metrics in addition to the global sysctls; Agreed. > route metrics take precedence over global sysctls. Agreed. > I don't object the per-socket settings though. However, IMHO, these > options (IW10 and ignoring idle restart, and probably others) are > administrative, so applications probably should not mess with them. Messing with individual options like IW10 on a per-socket basis is definitely in the "generally should not" basket, but I would not want to stop an application from doing so subject to the option being specified by the administrator in the net.inet.tcp.nonstandard.allowed option list. What I expect applications would want to do more frequently is hint the socket with a higher level goal e.g. "I want maximum throughput", "I want low latency", etc. This can come later though. I think we have enough agreement on the basic infrastructure to move forward at this point with some patches. I would initially like to get the basic sysctl infrastructure to support all this sorted, then look at supporting these options as route metrics, and finally look at the higher level API. Anyone else with further input, please speak up! Cheers, Lawrence ___ 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"
