Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation
On Sun, 10 Aug 2014, Florian Fainelli wrote:
> Le 10/08/2014 20:23, Dexuan Cui a écrit :
> >> -Original Message-
> >> From: Greg KH [mailto:gre...@linuxfoundation.org]
> >
> > IMO the most feasible and need-the-least-change solution may be:
> > the hyperv network VSC driver passes the event
> > RNDIS_STATUS_NETWORK_CHANGE to the udev daemon?
> >
> No, don't do that, again, act like any other network device, drop the
> link and bring it up when it comes back.
>
> >>> Hi Greg,
> >>> Do you mean tearing down the net device and re-creating it (by
> >>> register_netdev() and unregister_netdev)?
> >>
> >> No, don't you have link-detect for your network device? Toggle that, I
> >> thought patches to do this were posted a while ago...
> >>
> >> But if you really want to tear the whole network device down and then
> >> back up again, sure, that would also work.
> > Hi Greg, Stephen,
> >
> > Thanks for the comments!
> >
> > I suppose you meant the below logic:
> > if (refresh) {
> > rtnl_lock();
> > netif_carrier_off(net);
> > netif_carrier_on(net);
> > rtnl_unlock();
> > }
> >
> > We have discussed this in the previous mails of this thread itself:
> > e.g., http://marc.info/?l=linux-driver-devel=140593811715975=2
> >
> > Unluckily this logic doesn't work because the user-space daemons
> > like ifplugd, usually don't renew the DHCP immediately as long as they
> > receive a link-down message: they usually wait for some seconds and if
> > they find the link becomes up soon, they won't trigger renew operations.
> > (I guess this behavior can be somewhat reasonable: maybe the daemons
> > try to not trigger DHCP renew on temporary link instability)
>
> Is that such a big deal? If you know you spend much of your time in
> ifplugd, why not use something different that triggers a DHCP renewal
> faster, or fix ifplugd?
In the case of ifplugd, it has parameters -u | --delay-up= which
defaults to 0 seconds, and -d | --delay-down= which defaults to
5 seconds. Maybe for hyperv you could specify --delay-down=0.
I don't know if other daemons such as systemd have similar options.
It might still be good to have some modest delay between the
netif_carrier_off(net) and netif_carrier_on(net).
-Bill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation
On Sun, 10 Aug 2014, Florian Fainelli wrote:
Le 10/08/2014 20:23, Dexuan Cui a écrit :
-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org]
IMO the most feasible and need-the-least-change solution may be:
the hyperv network VSC driver passes the event
RNDIS_STATUS_NETWORK_CHANGE to the udev daemon?
No, don't do that, again, act like any other network device, drop the
link and bring it up when it comes back.
Hi Greg,
Do you mean tearing down the net device and re-creating it (by
register_netdev() and unregister_netdev)?
No, don't you have link-detect for your network device? Toggle that, I
thought patches to do this were posted a while ago...
But if you really want to tear the whole network device down and then
back up again, sure, that would also work.
Hi Greg, Stephen,
Thanks for the comments!
I suppose you meant the below logic:
if (refresh) {
rtnl_lock();
netif_carrier_off(net);
netif_carrier_on(net);
rtnl_unlock();
}
We have discussed this in the previous mails of this thread itself:
e.g., http://marc.info/?l=linux-driver-develm=140593811715975w=2
Unluckily this logic doesn't work because the user-space daemons
like ifplugd, usually don't renew the DHCP immediately as long as they
receive a link-down message: they usually wait for some seconds and if
they find the link becomes up soon, they won't trigger renew operations.
(I guess this behavior can be somewhat reasonable: maybe the daemons
try to not trigger DHCP renew on temporary link instability)
Is that such a big deal? If you know you spend much of your time in
ifplugd, why not use something different that triggers a DHCP renewal
faster, or fix ifplugd?
In the case of ifplugd, it has parameters -u | --delay-up= which
defaults to 0 seconds, and -d | --delay-down= which defaults to
5 seconds. Maybe for hyperv you could specify --delay-down=0.
I don't know if other daemons such as systemd have similar options.
It might still be good to have some modest delay between the
netif_carrier_off(net) and netif_carrier_on(net).
-Bill
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address
On Wed, 12 Feb 2014, Ian Campbell wrote: > On Tue, 2014-02-11 at 13:53 -0800, Luis R. Rodriguez wrote: > > Cc'ing kvm folks as they may have a shared interest on the shared > > physical case with the bridge (non NAT). > > > > On Tue, Feb 11, 2014 at 12:43 AM, Ian Campbell > > wrote: > > > On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote: > > >> From: "Luis R. Rodriguez" > > >> > > >> Although the xen-netback interfaces do not participate in the > > >> link as a typical Ethernet device interfaces for them are > > >> still required under the current archtitecture. IPv6 addresses > > >> do not need to be created or assigned on the xen-netback interfaces > > >> however, even if the frontend devices do need them, so clear the > > >> multicast flag to ensure the net core does not initiate IPv6 > > >> Stateless Address Autoconfiguration. > > > > > > How does disabling SAA flow from the absence of multicast? > > > > See patch 1 in this series [0], but I explain the issue I see with > > this on the cover letter [1]. > > Oop, I felt like I'd missed some context. Thanks for pointing out that > it was right under my nose. > > > In summary the RFCs on IPv6 make it > > clear you need multicast for Stateless address autoconfiguration > > (SLAAC is the preferred acronym) and DAD, > > That seems reasonable, but I think is the opposite to what I was trying > to get at. > > Why is it not possible to disable SLAAC and/or DAD even if multicast is > present? > > IOW -- enabling/disabling multicast seems to me to be an odd proxy for > disabling SLAAC or DAD and AIUI your patch fixes the opposite case, > which is to avoid SLAAC and DAD on interfaces which don't do multicast > (which makes sense since those protocols involve multicast). Forgive me if this doesn't make sense in this context since I'm not a kernel developer, but I was just wondering if any of the sysctls: /proc/sys/net/ipv6/conf//disable_ipv6 /proc/sys/net/ipv6/conf//accept_dad /proc/sys/net/ipv6/conf//accept_ra /proc/sys/net/ipv6/conf//autoconf would be apropos for the requirement being discussed. -Bill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/2] xen-netback: disable multicast and use a random hw MAC address
On Wed, 12 Feb 2014, Ian Campbell wrote: On Tue, 2014-02-11 at 13:53 -0800, Luis R. Rodriguez wrote: Cc'ing kvm folks as they may have a shared interest on the shared physical case with the bridge (non NAT). On Tue, Feb 11, 2014 at 12:43 AM, Ian Campbell ian.campb...@citrix.com wrote: On Mon, 2014-02-10 at 14:29 -0800, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@suse.com Although the xen-netback interfaces do not participate in the link as a typical Ethernet device interfaces for them are still required under the current archtitecture. IPv6 addresses do not need to be created or assigned on the xen-netback interfaces however, even if the frontend devices do need them, so clear the multicast flag to ensure the net core does not initiate IPv6 Stateless Address Autoconfiguration. How does disabling SAA flow from the absence of multicast? See patch 1 in this series [0], but I explain the issue I see with this on the cover letter [1]. Oop, I felt like I'd missed some context. Thanks for pointing out that it was right under my nose. In summary the RFCs on IPv6 make it clear you need multicast for Stateless address autoconfiguration (SLAAC is the preferred acronym) and DAD, That seems reasonable, but I think is the opposite to what I was trying to get at. Why is it not possible to disable SLAAC and/or DAD even if multicast is present? IOW -- enabling/disabling multicast seems to me to be an odd proxy for disabling SLAAC or DAD and AIUI your patch fixes the opposite case, which is to avoid SLAAC and DAD on interfaces which don't do multicast (which makes sense since those protocols involve multicast). Forgive me if this doesn't make sense in this context since I'm not a kernel developer, but I was just wondering if any of the sysctls: /proc/sys/net/ipv6/conf/ifc/disable_ipv6 /proc/sys/net/ipv6/conf/ifc/accept_dad /proc/sys/net/ipv6/conf/ifc/accept_ra /proc/sys/net/ipv6/conf/ifc/autoconf would be apropos for the requirement being discussed. -Bill -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: rfkill-regulator: Add devicetree support.
On Fri, 7 Feb 2014, Marek Belisko wrote:
> Signed-off-by: NeilBrown
> Signed-off-by: Marek Belisko
> ---
> Based on Neil's patch and extend for documentation and bindings include.
>
> .../bindings/net/rfkill/rfkill-relugator.txt | 28
^
Typo in file name.
-Bill
> include/dt-bindings/net/rfkill-regulator.h | 23 +
> net/rfkill/rfkill-regulator.c | 38
> ++
> 3 files changed, 89 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
> create mode 100644 include/dt-bindings/net/rfkill-regulator.h
>
> diff --git
> a/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
> b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
> new file mode 100644
> index 000..cdb7dd7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
> @@ -0,0 +1,28 @@
> +Regulator consumer for rfkill devices
> +
> +Required properties:
> +- compatible : Must be "rfkill-regulator".
> +- label : Name of rfkill device.
> +- type : Type of rfkill device.
> +
> +Possible values (defined in include/dt-bindings/net/rfkill-regulator.h):
> + RFKILL_TYPE_ALL
> + RFKILL_TYPE_WLAN
> + RFKILL_TYPE_BLUETOOTH
> + RFKILL_TYPE_UWB
> + RFKILL_TYPE_WIMAX
> + RFKILL_TYPE_WWAN
> + RFKILL_TYPE_GPS
> + RFKILL_TYPE_FM
> + RFKILL_TYPE_NFC
> +
> +- vrfkill-supply - regulator device.
> +
> +Example:
> + gps-rfkill {
> + compatible = "rfkill-regulator";
> + label = "GPS";
> + type = ;
> + vrfkill-supply = <>;
> + };
> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: rfkill-regulator: Add devicetree support.
On Fri, 7 Feb 2014, Marek Belisko wrote:
Signed-off-by: NeilBrown ne...@suse.de
Signed-off-by: Marek Belisko ma...@goldelico.com
---
Based on Neil's patch and extend for documentation and bindings include.
.../bindings/net/rfkill/rfkill-relugator.txt | 28
^
Typo in file name.
-Bill
include/dt-bindings/net/rfkill-regulator.h | 23 +
net/rfkill/rfkill-regulator.c | 38
++
3 files changed, 89 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
create mode 100644 include/dt-bindings/net/rfkill-regulator.h
diff --git
a/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
new file mode 100644
index 000..cdb7dd7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
@@ -0,0 +1,28 @@
+Regulator consumer for rfkill devices
+
+Required properties:
+- compatible : Must be rfkill-regulator.
+- label : Name of rfkill device.
+- type : Type of rfkill device.
+
+Possible values (defined in include/dt-bindings/net/rfkill-regulator.h):
+ RFKILL_TYPE_ALL
+ RFKILL_TYPE_WLAN
+ RFKILL_TYPE_BLUETOOTH
+ RFKILL_TYPE_UWB
+ RFKILL_TYPE_WIMAX
+ RFKILL_TYPE_WWAN
+ RFKILL_TYPE_GPS
+ RFKILL_TYPE_FM
+ RFKILL_TYPE_NFC
+
+- vrfkill-supply - regulator device.
+
+Example:
+ gps-rfkill {
+ compatible = rfkill-regulator;
+ label = GPS;
+ type = RFKILL_TYPE_GPS;
+ vrfkill-supply = reg;
+ };
+
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: e1000 full-duplex TCP performance well below wire speed
Hi Bruce, On Thu, 31 Jan 2008, Bruce Allen wrote: > > I see similar results on my test systems > > Thanks for this report and for confirming our observations. Could you > please confirm that a single-port bidrectional UDP link runs at wire > speed? This helps to localize the problem to the TCP stack or interaction > of the TCP stack with the e1000 driver and hardware. Yes, a single-port bidirectional UDP test gets full GigE line rate in both directions with no packet loss. [EMAIL PROTECTED] ~]$ nuttcp -f-beta -Itx -u -Ru -w2m 192.168.6.79 & nuttcp -f-beta -Irx -r -u -Ru -w2m 192.168.6.79 tx: 1187.0078 MB / 10.04 sec = 992.0550 Mbps 19 %TX 7 %RX 0 / 151937 drop/pkt 0.00 %loss rx: 1187.1016 MB / 10.03 sec = 992.3408 Mbps 19 %TX 7 %RX 0 / 151949 drop/pkt 0.00 %loss -Bill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: e1000 full-duplex TCP performance well below wire speed
On Wed, 30 Jan 2008, SANGTAE HA wrote: > On Jan 30, 2008 5:25 PM, Bruce Allen <[EMAIL PROTECTED]> wrote: > > > > In our application (cluster computing) we use a very tightly coupled > > high-speed low-latency network. There is no 'wide area traffic'. So it's > > hard for me to understand why any networking components or software layers > > should take more than milliseconds to ramp up or back off in speed. > > Perhaps we should be asking for a TCP congestion avoidance algorithm which > > is designed for a data center environment where there are very few hops > > and typical packet delivery times are tens or hundreds of microseconds. > > It's very different than delivering data thousands of km across a WAN. > > > > If your network latency is low, regardless of type of protocols should > give you more than 900Mbps. I can guess the RTT of two machines is > less than 4ms in your case and I remember the throughputs of all > high-speed protocols (including tcp-reno) were more than 900Mbps with > 4ms RTT. So, my question which kernel version did you use with your > broadcomm NIC and got more than 900Mbps? > > I have two machines connected by a gig switch and I can see what > happens in my environment. Could you post what parameters did you use > for netperf testing? > and also if you set any parameters for your testing, please post them > here so that I can see that happens to me as well. I see similar results on my test systems, using Tyan Thunder K8WE (S2895) motherboard with dual Intel Xeon 3.06 GHZ CPUs and 1 GB memory, running a 2.6.15.4 kernel. The GigE NICs are Intel PRO/1000 82546EB_QUAD_COPPER, on a 64-bit/133-MHz PCI-X bus, using version 6.1.16-k2 of the e1000 driver, and running with 9000-byte jumbo frames. The TCP congestion control is BIC. Unidirectional TCP test: [EMAIL PROTECTED] ~]$ nuttcp -f-beta -Itx -w2m 192.168.6.79 tx: 1186.5649 MB / 10.05 sec = 990.2741 Mbps 11 %TX 9 %RX 0 retrans and: [EMAIL PROTECTED] ~]$ nuttcp -f-beta -Irx -r -w2m 192.168.6.79 rx: 1186.8281 MB / 10.05 sec = 990.5634 Mbps 14 %TX 9 %RX 0 retrans Each direction gets full GigE line rate. Bidirectional TCP test: [EMAIL PROTECTED] ~]$ nuttcp -f-beta -Itx -w2m 192.168.6.79 & nuttcp -f-beta -Irx -r -w2m 192.168.6.79 tx: 898.9934 MB / 10.05 sec = 750.1634 Mbps 10 %TX 8 %RX 0 retrans rx: 1167.3750 MB / 10.06 sec = 973.8617 Mbps 14 %TX 11 %RX 0 retrans While one direction gets close to line rate, the other only got 750 Mbps. Note there were no TCP retransmitted segments for either data stream, so that doesn't appear to be the cause of the slower transfer rate in one direction. If the receive direction uses a different GigE NIC that's part of the same quad-GigE, all is fine: [EMAIL PROTECTED] ~]$ nuttcp -f-beta -Itx -w2m 192.168.6.79 & nuttcp -f-beta -Irx -r -w2m 192.168.5.79 tx: 1186.5051 MB / 10.05 sec = 990.2250 Mbps 12 %TX 13 %RX 0 retrans rx: 1186.7656 MB / 10.05 sec = 990.5204 Mbps 15 %TX 14 %RX 0 retrans Here's a test using the same GigE NIC for both directions with 1-second interval reports: [EMAIL PROTECTED] ~]$ nuttcp -f-beta -Itx -i1 -w2m 192.168.6.79 & nuttcp -f-beta -Irx -r -i1 -w2m 192.168.6.79 tx:92.3750 MB / 1.01 sec = 767.2277 Mbps 0 retrans rx: 104.5625 MB / 1.01 sec = 872.4757 Mbps 0 retrans tx:83.3125 MB / 1.00 sec = 700.1845 Mbps 0 retrans rx: 117.6250 MB / 1.00 sec = 986.5541 Mbps 0 retrans tx:83.8125 MB / 1.00 sec = 703.0322 Mbps 0 retrans rx: 117.6250 MB / 1.00 sec = 986.5502 Mbps 0 retrans tx:83. MB / 1.00 sec = 696.1779 Mbps 0 retrans rx: 117.6250 MB / 1.00 sec = 986.5522 Mbps 0 retrans tx:83.7500 MB / 1.00 sec = 702.4989 Mbps 0 retrans rx: 117.6250 MB / 1.00 sec = 986.5512 Mbps 0 retrans tx:83.1250 MB / 1.00 sec = 697.2270 Mbps 0 retrans rx: 117.6250 MB / 1.00 sec = 986.5512 Mbps 0 retrans tx:84.1875 MB / 1.00 sec = 706.1665 Mbps 0 retrans rx: 117.5625 MB / 1.00 sec = 985.5510 Mbps 0 retrans tx:83.0625 MB / 1.00 sec = 696.7167 Mbps 0 retrans rx: 117.6875 MB / 1.00 sec = 987.5543 Mbps 0 retrans tx:84.1875 MB / 1.00 sec = 706.1545 Mbps 0 retrans rx: 117.6250 MB / 1.00 sec = 986.5472 Mbps 0 retrans rx: 117.6875 MB / 1.00 sec = 987.0724 Mbps 0 retrans tx:83.3125 MB / 1.00 sec = 698.8137 Mbps 0 retrans tx: 844.9375 MB / 10.07 sec = 703.7699 Mbps 11 %TX 6 %RX 0 retrans rx: 1167.4414 MB / 10.05 sec = 973.9980 Mbps 14 %TX 11 %RX 0 retrans In this test case, the receiver ramped up to nearly full GigE line rate, while the transmitter was stuck at about 700 Mbps. I ran one longer 60-second test and didn't see the oscillating behavior between receiver and transmitter, but maybe that's because I have the GigE NIC interrupts and nuttcp client/server applications both locked to CPU 0. So in my tests, once one direction gets the upper hand, it seems to stay that way.
Re: e1000 full-duplex TCP performance well below wire speed
On Wed, 30 Jan 2008, SANGTAE HA wrote: On Jan 30, 2008 5:25 PM, Bruce Allen [EMAIL PROTECTED] wrote: In our application (cluster computing) we use a very tightly coupled high-speed low-latency network. There is no 'wide area traffic'. So it's hard for me to understand why any networking components or software layers should take more than milliseconds to ramp up or back off in speed. Perhaps we should be asking for a TCP congestion avoidance algorithm which is designed for a data center environment where there are very few hops and typical packet delivery times are tens or hundreds of microseconds. It's very different than delivering data thousands of km across a WAN. If your network latency is low, regardless of type of protocols should give you more than 900Mbps. I can guess the RTT of two machines is less than 4ms in your case and I remember the throughputs of all high-speed protocols (including tcp-reno) were more than 900Mbps with 4ms RTT. So, my question which kernel version did you use with your broadcomm NIC and got more than 900Mbps? I have two machines connected by a gig switch and I can see what happens in my environment. Could you post what parameters did you use for netperf testing? and also if you set any parameters for your testing, please post them here so that I can see that happens to me as well. I see similar results on my test systems, using Tyan Thunder K8WE (S2895) motherboard with dual Intel Xeon 3.06 GHZ CPUs and 1 GB memory, running a 2.6.15.4 kernel. The GigE NICs are Intel PRO/1000 82546EB_QUAD_COPPER, on a 64-bit/133-MHz PCI-X bus, using version 6.1.16-k2 of the e1000 driver, and running with 9000-byte jumbo frames. The TCP congestion control is BIC. Unidirectional TCP test: [EMAIL PROTECTED] ~]$ nuttcp -f-beta -Itx -w2m 192.168.6.79 tx: 1186.5649 MB / 10.05 sec = 990.2741 Mbps 11 %TX 9 %RX 0 retrans and: [EMAIL PROTECTED] ~]$ nuttcp -f-beta -Irx -r -w2m 192.168.6.79 rx: 1186.8281 MB / 10.05 sec = 990.5634 Mbps 14 %TX 9 %RX 0 retrans Each direction gets full GigE line rate. Bidirectional TCP test: [EMAIL PROTECTED] ~]$ nuttcp -f-beta -Itx -w2m 192.168.6.79 nuttcp -f-beta -Irx -r -w2m 192.168.6.79 tx: 898.9934 MB / 10.05 sec = 750.1634 Mbps 10 %TX 8 %RX 0 retrans rx: 1167.3750 MB / 10.06 sec = 973.8617 Mbps 14 %TX 11 %RX 0 retrans While one direction gets close to line rate, the other only got 750 Mbps. Note there were no TCP retransmitted segments for either data stream, so that doesn't appear to be the cause of the slower transfer rate in one direction. If the receive direction uses a different GigE NIC that's part of the same quad-GigE, all is fine: [EMAIL PROTECTED] ~]$ nuttcp -f-beta -Itx -w2m 192.168.6.79 nuttcp -f-beta -Irx -r -w2m 192.168.5.79 tx: 1186.5051 MB / 10.05 sec = 990.2250 Mbps 12 %TX 13 %RX 0 retrans rx: 1186.7656 MB / 10.05 sec = 990.5204 Mbps 15 %TX 14 %RX 0 retrans Here's a test using the same GigE NIC for both directions with 1-second interval reports: [EMAIL PROTECTED] ~]$ nuttcp -f-beta -Itx -i1 -w2m 192.168.6.79 nuttcp -f-beta -Irx -r -i1 -w2m 192.168.6.79 tx:92.3750 MB / 1.01 sec = 767.2277 Mbps 0 retrans rx: 104.5625 MB / 1.01 sec = 872.4757 Mbps 0 retrans tx:83.3125 MB / 1.00 sec = 700.1845 Mbps 0 retrans rx: 117.6250 MB / 1.00 sec = 986.5541 Mbps 0 retrans tx:83.8125 MB / 1.00 sec = 703.0322 Mbps 0 retrans rx: 117.6250 MB / 1.00 sec = 986.5502 Mbps 0 retrans tx:83. MB / 1.00 sec = 696.1779 Mbps 0 retrans rx: 117.6250 MB / 1.00 sec = 986.5522 Mbps 0 retrans tx:83.7500 MB / 1.00 sec = 702.4989 Mbps 0 retrans rx: 117.6250 MB / 1.00 sec = 986.5512 Mbps 0 retrans tx:83.1250 MB / 1.00 sec = 697.2270 Mbps 0 retrans rx: 117.6250 MB / 1.00 sec = 986.5512 Mbps 0 retrans tx:84.1875 MB / 1.00 sec = 706.1665 Mbps 0 retrans rx: 117.5625 MB / 1.00 sec = 985.5510 Mbps 0 retrans tx:83.0625 MB / 1.00 sec = 696.7167 Mbps 0 retrans rx: 117.6875 MB / 1.00 sec = 987.5543 Mbps 0 retrans tx:84.1875 MB / 1.00 sec = 706.1545 Mbps 0 retrans rx: 117.6250 MB / 1.00 sec = 986.5472 Mbps 0 retrans rx: 117.6875 MB / 1.00 sec = 987.0724 Mbps 0 retrans tx:83.3125 MB / 1.00 sec = 698.8137 Mbps 0 retrans tx: 844.9375 MB / 10.07 sec = 703.7699 Mbps 11 %TX 6 %RX 0 retrans rx: 1167.4414 MB / 10.05 sec = 973.9980 Mbps 14 %TX 11 %RX 0 retrans In this test case, the receiver ramped up to nearly full GigE line rate, while the transmitter was stuck at about 700 Mbps. I ran one longer 60-second test and didn't see the oscillating behavior between receiver and transmitter, but maybe that's because I have the GigE NIC interrupts and nuttcp client/server applications both locked to CPU 0. So in my tests, once one direction gets the upper hand, it seems to stay that way. Could this be because the slower side
Re: e1000 full-duplex TCP performance well below wire speed
Hi Bruce, On Thu, 31 Jan 2008, Bruce Allen wrote: I see similar results on my test systems Thanks for this report and for confirming our observations. Could you please confirm that a single-port bidrectional UDP link runs at wire speed? This helps to localize the problem to the TCP stack or interaction of the TCP stack with the e1000 driver and hardware. Yes, a single-port bidirectional UDP test gets full GigE line rate in both directions with no packet loss. [EMAIL PROTECTED] ~]$ nuttcp -f-beta -Itx -u -Ru -w2m 192.168.6.79 nuttcp -f-beta -Irx -r -u -Ru -w2m 192.168.6.79 tx: 1187.0078 MB / 10.04 sec = 992.0550 Mbps 19 %TX 7 %RX 0 / 151937 drop/pkt 0.00 %loss rx: 1187.1016 MB / 10.03 sec = 992.3408 Mbps 19 %TX 7 %RX 0 / 151949 drop/pkt 0.00 %loss -Bill -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/10] e1000e: make E1000E default to the same kconfig setting as E1000
On Fri, 14 Dec 2007, Andrew Morton wrote: > On Fri, 14 Dec 2007 15:39:26 -0500 > Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > [EMAIL PROTECTED] wrote: > > > From: Randy Dunlap <[EMAIL PROTECTED]> > > > > > > Make E1000E default to the same kconfig setting as E1000. So people's > > > machiens don't stop working when they use oldconfig. > > > > > I am not inclined to apply this one. This practice, applied over time, > > will tend to accumulate weird 'default' and 'select' statements. > > > > So I think the breakage that occurs is mitigated by two factors: > > 1) kernel hackers that do their own configs are expected to be able to > > figure this stuff. > > 2) kernel builders (read: distros, mainly) are expected to have put > > thought into the Kconfig selection and driver migration strategies. > > > > PCI IDs move across drivers from time, and we don't want to apply these > > sorts changes: Viewed in the long term, the suggested patch is merely a > > temporary change to allow kernel experts to more easily deal with the > > PCI ID migration across drivers. > > > > I would prefer simply to communicate to kernel experts and builders > > about a Kconfig issue that could potentially their booting/networking... > > because this patch is only needed if the kernel experts do not already > > know about a necessary config update. > > You can take it out again later on - most people's .configs will then have > E1000E set. People who still do `cp ancientconfig .config ; make oldconfig' > remain screwed. I was thinking the same thing. Leave it in for 2 or 3 major versions and then remove it (something analogous to the timeframe for a feature removal). And during the interim period, add something like the following to the Kconfig help text: Note some hardware that was previously supported by the e1000 driver is now only handled by the e1000e driver. If unsure and you previously used the e1000 driver, say Y or M here. > I dunno. I guess I'm not into causing people pain in an attempt to train > them to do what we want. This is a popular driver and a *lot* of people > are going to: > > - build new kernel > > - install new kernel > > - find it doesn't work, go through quite large amounts of hassle trying > to work out why it stopped working. Eventually work out that e1000 > stopped working. Eventually work out that it stopped working because we > forcibly switched them to a new driver which they didn't know about. > > - reconfigure kernel > > - rebuild, reinstall Having been there, done that, it's definitely a pain. It's especially painful when you're doing it remotely, and since the network no longer works, you can't get into the system anymore. > Multiply that by 100s of people (at least). All because Jeff wouldn't > apply a one-liner? -Bill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/10] e1000e: make E1000E default to the same kconfig setting as E1000
On Fri, 14 Dec 2007, Andrew Morton wrote: On Fri, 14 Dec 2007 15:39:26 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: From: Randy Dunlap [EMAIL PROTECTED] Make E1000E default to the same kconfig setting as E1000. So people's machiens don't stop working when they use oldconfig. I am not inclined to apply this one. This practice, applied over time, will tend to accumulate weird 'default' and 'select' statements. So I think the breakage that occurs is mitigated by two factors: 1) kernel hackers that do their own configs are expected to be able to figure this stuff. 2) kernel builders (read: distros, mainly) are expected to have put thought into the Kconfig selection and driver migration strategies. PCI IDs move across drivers from time, and we don't want to apply these sorts changes: Viewed in the long term, the suggested patch is merely a temporary change to allow kernel experts to more easily deal with the PCI ID migration across drivers. I would prefer simply to communicate to kernel experts and builders about a Kconfig issue that could potentially their booting/networking... because this patch is only needed if the kernel experts do not already know about a necessary config update. You can take it out again later on - most people's .configs will then have E1000E set. People who still do `cp ancientconfig .config ; make oldconfig' remain screwed. I was thinking the same thing. Leave it in for 2 or 3 major versions and then remove it (something analogous to the timeframe for a feature removal). And during the interim period, add something like the following to the Kconfig help text: Note some hardware that was previously supported by the e1000 driver is now only handled by the e1000e driver. If unsure and you previously used the e1000 driver, say Y or M here. I dunno. I guess I'm not into causing people pain in an attempt to train them to do what we want. This is a popular driver and a *lot* of people are going to: - build new kernel - install new kernel - find it doesn't work, go through quite large amounts of hassle trying to work out why it stopped working. Eventually work out that e1000 stopped working. Eventually work out that it stopped working because we forcibly switched them to a new driver which they didn't know about. - reconfigure kernel - rebuild, reinstall Having been there, done that, it's definitely a pain. It's especially painful when you're doing it remotely, and since the network no longer works, you can't get into the system anymore. Multiply that by 100s of people (at least). All because Jeff wouldn't apply a one-liner? -Bill -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0 (was: Strange behavior in arp probe reply, bug or feature?)
On Mon, 19 Nov 2007, Alexey Kuznetsov wrote: > Hello! > > > Is there a reason that the target hardware address isn't the target > > hardware address? > > It is bound only to the fact that linux uses protocol address > of the machine, which responds. It would be highly confusing > (more than confusing :-)), if we used our protocol address and hardware > address of requestor. > > But if you use zero protocol address as source, you really can use > any hw address. > > > The dhcp clients I examined, and the implementation of the arpcheck > > that I use will compare the target hardware field of the arp-reply and > > match it against its own mac, to verify the reply. And this fails with > > the current implementation in the kernel. > > 1. Do not do this. Mainly, because you already know that this does not work >with linux. :-) Logically, target hw address in arp reply is just >a nonsensial redundancy, it should not be checked and even looked at. Repeating what I posted earlier from the ARP RFC 826: "The target hardware address is included for completeness and network monitoring. It has no meaning in the request form, since it is this number that the machine is requesting. Its meaning in the reply form is the address of the machine making the request. In some implementations (which do not get to look at the 14.byte ethernet header, for example) this may save some register shuffling or stack space by sending this field to the hardware driver as the hardware destination address of the packet. Unless there is some other RFC that supercedes this, which doesn't appear to be the case since it's also STD37, it appears to me that the current Linux behavior is wrong. It clearly states that for the ARP reply, the target hardware address is "the address of the machine making the request", and not the address of the machine making the reply as Linux is apparently doing. > 2. What's about your suggestion, I thought about this and I am going to agree. > >Arguments, which convinced me are: > >- arping still works. >- any piece of reasonable software should work. >- if Windows understands DaD (is it really true? I cannot believe) > and it is unhappy about our responce and does not block use > of duplicate address only due to this, we _must_ accomodate ASAP. >- if we do,we have to use 0 protocol address, no choice. I agree the target protocol address should be 0 in this case. -Bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0 (was: Strange behavior in arp probe reply, bug or feature?)
On Mon, 19 Nov 2007, Alexey Kuznetsov wrote: Hello! Is there a reason that the target hardware address isn't the target hardware address? It is bound only to the fact that linux uses protocol address of the machine, which responds. It would be highly confusing (more than confusing :-)), if we used our protocol address and hardware address of requestor. But if you use zero protocol address as source, you really can use any hw address. The dhcp clients I examined, and the implementation of the arpcheck that I use will compare the target hardware field of the arp-reply and match it against its own mac, to verify the reply. And this fails with the current implementation in the kernel. 1. Do not do this. Mainly, because you already know that this does not work with linux. :-) Logically, target hw address in arp reply is just a nonsensial redundancy, it should not be checked and even looked at. Repeating what I posted earlier from the ARP RFC 826: The target hardware address is included for completeness and network monitoring. It has no meaning in the request form, since it is this number that the machine is requesting. Its meaning in the reply form is the address of the machine making the request. In some implementations (which do not get to look at the 14.byte ethernet header, for example) this may save some register shuffling or stack space by sending this field to the hardware driver as the hardware destination address of the packet. Unless there is some other RFC that supercedes this, which doesn't appear to be the case since it's also STD37, it appears to me that the current Linux behavior is wrong. It clearly states that for the ARP reply, the target hardware address is the address of the machine making the request, and not the address of the machine making the reply as Linux is apparently doing. 2. What's about your suggestion, I thought about this and I am going to agree. Arguments, which convinced me are: - arping still works. - any piece of reasonable software should work. - if Windows understands DaD (is it really true? I cannot believe) and it is unhappy about our responce and does not block use of duplicate address only due to this, we _must_ accomodate ASAP. - if we do,we have to use 0 protocol address, no choice. I agree the target protocol address should be 0 in this case. -Bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0
On Fri, 16 Nov 2007, David Miller wrote: > From: "Jonas Danielsson" <[EMAIL PROTECTED]> > Date: Fri, 16 Nov 2007 09:30:11 +0100 > > > 2007/11/16, David Miller <[EMAIL PROTECTED]>: > > > From: "Jonas Danielsson" <[EMAIL PROTECTED]> > > > Date: Thu, 15 Nov 2007 22:40:13 +0100 > > > > > > > Is there a reason that the target hardware address isn't the target > > > > hardware address? > > > > > Because of this, in cases where a choice can be made Linux will > > > advertise what is most likely to result in successful communication. > > > > > > This is likely why we are changing that target address to the one of > > > the interface actually sending back the reply rather than the zero > > > value you used. > > > > > > In fact I think this information can be useful to the sender of > > > the DAD request. > > > > > > > There seem to be some confusion about what my patch really does. It > > does not set the hardware address to a zero value. > > I knew you were talking about the IP address not the hardware > address. > > > The reply from the Linux kernel in computer A, before the patch would look > > like: > > > > Reply: > > Opcode: reply (0x0002) > > Sender HW: 00:AA.00:AA:00:AA > > Sender IP: 192.168.0.1 > > Target HW: 00:AA:00:AA:00:AA > > Target IP:192.168.0.1 > > And this is exactly a sensible response in my opinion. I don't see how you can say that, since it appears to be in violation of RFC 826: "The target hardware address is included for completeness and network monitoring. It has no meaning in the request form, since it is this number that the machine is requesting. Its meaning in the reply form is the address of the machine making the request. In some implementations (which do not get to look at the 14.byte ethernet header, for example) this may save some register shuffling or stack space by sending this field to the hardware driver as the hardware destination address of the packet." Since the MAC address of the machine making the request is 00:BB:00:BB:00:BB, and not 00:AA:00:AA:00:AA, Linux appears to be in violation of the ARP RFC. Regarding the Target IP, RFC 826 says: "The target protocol address is necessary in the request form of the packet so that a machine can determine whether or not to enter the sender information in a table or to send a reply. It is not necessarily needed in the reply form if one assumes a reply is only provoked by a request. It is included for completeness, network monitoring, and to simplify the suggested processing algorithm described above (which does not look at the opcode until AFTER putting the sender information in a table). So it's ambiguous about the target IP address in an ARP reply packet, but a value of 0.0.0.0 makes more logical sense to me than using 192.168.0.1 in this example case, since it should reflect the requestor IP address, which is unknown in this case. -Bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0
On Fri, 16 Nov 2007, David Miller wrote: From: Jonas Danielsson [EMAIL PROTECTED] Date: Fri, 16 Nov 2007 09:30:11 +0100 2007/11/16, David Miller [EMAIL PROTECTED]: From: Jonas Danielsson [EMAIL PROTECTED] Date: Thu, 15 Nov 2007 22:40:13 +0100 Is there a reason that the target hardware address isn't the target hardware address? Because of this, in cases where a choice can be made Linux will advertise what is most likely to result in successful communication. This is likely why we are changing that target address to the one of the interface actually sending back the reply rather than the zero value you used. In fact I think this information can be useful to the sender of the DAD request. There seem to be some confusion about what my patch really does. It does not set the hardware address to a zero value. I knew you were talking about the IP address not the hardware address. The reply from the Linux kernel in computer A, before the patch would look like: Reply: Opcode: reply (0x0002) Sender HW: 00:AA.00:AA:00:AA Sender IP: 192.168.0.1 Target HW: 00:AA:00:AA:00:AA Target IP:192.168.0.1 And this is exactly a sensible response in my opinion. I don't see how you can say that, since it appears to be in violation of RFC 826: The target hardware address is included for completeness and network monitoring. It has no meaning in the request form, since it is this number that the machine is requesting. Its meaning in the reply form is the address of the machine making the request. In some implementations (which do not get to look at the 14.byte ethernet header, for example) this may save some register shuffling or stack space by sending this field to the hardware driver as the hardware destination address of the packet. Since the MAC address of the machine making the request is 00:BB:00:BB:00:BB, and not 00:AA:00:AA:00:AA, Linux appears to be in violation of the ARP RFC. Regarding the Target IP, RFC 826 says: The target protocol address is necessary in the request form of the packet so that a machine can determine whether or not to enter the sender information in a table or to send a reply. It is not necessarily needed in the reply form if one assumes a reply is only provoked by a request. It is included for completeness, network monitoring, and to simplify the suggested processing algorithm described above (which does not look at the opcode until AFTER putting the sender information in a table). So it's ambiguous about the target IP address in an ARP reply packet, but a value of 0.0.0.0 makes more logical sense to me than using 192.168.0.1 in this example case, since it should reflect the requestor IP address, which is unknown in this case. -Bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: In search of 10gbps cards/shootout in Linux?
On Sat, 8 Sep 2007, Justin Piszcz wrote: > There are various agencies/educational institutions doing testing but was > curious if anyone has 'found' a 10 gigabit card shootout measuring the > performance between 10 gigabit cards on the 2.6 kernel? Most of the > benchmarks are from the vendors themselves Intel/etc-- was wondering if > there were any vendor-independent benchmarks out there? > > Until switches come down in price, 10gbps will be most relegated to > business/research use and therefore such benchmarks probably will be hard > to come by but I thought I'd ask.. I haven't done any comparisons with other vendor offerings, but I can highly recommend the Myricom PCI-Express (8x) 10-GigE NICs. They only cost about $900 and can do full unidirectional 10-GigE line rate. And as a 10-GigE router, they can do full bidirectional 10-GigE line rate IP forwarding. Note the choice of system/motherboard/CPU is as important as the choice of NIC in achieving maximum performance. Sample nuttcp test: chance7 -> chance9 10-second TCP test: [EMAIL PROTECTED] ~]# nuttcp -w10m 192.168.88.16 11817.8125 MB / 10.00 sec = 9909.8073 Mbps 100 %TX 71 %RX The system specs are: Tyan Thunder K8WE S2895ANRF motherboard with Nvidia nForce Professional 2200+2050 chipset, 2 AMD Opteron 254 2.8 GHz CPUs, 4 GB PC3200 ECC REG-DDR 400 memory, and 2 PCI-Express x16 slots (2 buses). The systems are running a 2.6.20.7 kernel. Perhaps others can share their experiences with 10-GigE NICs. -Bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: In search of 10gbps cards/shootout in Linux?
On Sat, 8 Sep 2007, Justin Piszcz wrote: There are various agencies/educational institutions doing testing but was curious if anyone has 'found' a 10 gigabit card shootout measuring the performance between 10 gigabit cards on the 2.6 kernel? Most of the benchmarks are from the vendors themselves Intel/etc-- was wondering if there were any vendor-independent benchmarks out there? Until switches come down in price, 10gbps will be most relegated to business/research use and therefore such benchmarks probably will be hard to come by but I thought I'd ask.. I haven't done any comparisons with other vendor offerings, but I can highly recommend the Myricom PCI-Express (8x) 10-GigE NICs. They only cost about $900 and can do full unidirectional 10-GigE line rate. And as a 10-GigE router, they can do full bidirectional 10-GigE line rate IP forwarding. Note the choice of system/motherboard/CPU is as important as the choice of NIC in achieving maximum performance. Sample nuttcp test: chance7 - chance9 10-second TCP test: [EMAIL PROTECTED] ~]# nuttcp -w10m 192.168.88.16 11817.8125 MB / 10.00 sec = 9909.8073 Mbps 100 %TX 71 %RX The system specs are: Tyan Thunder K8WE S2895ANRF motherboard with Nvidia nForce Professional 2200+2050 chipset, 2 AMD Opteron 254 2.8 GHz CPUs, 4 GB PC3200 ECC REG-DDR 400 memory, and 2 PCI-Express x16 slots (2 buses). The systems are running a 2.6.20.7 kernel. Perhaps others can share their experiences with 10-GigE NICs. -Bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
On Wed, 15 Aug 2007, Satyam Sharma wrote:
> (C)
> $ cat tp3.c
> int a;
>
> void func(void)
> {
> *(volatile int *) = 10;
> *(volatile int *) = 20;
> }
> $ gcc -Os -S tp3.c
> $ cat tp3.s
> ...
> movl$10, a
> movl$20, a
> ...
I'm curious about one minor tangential point. Why, instead of:
b = *(volatile int *)
why can't this just be expressed as:
b = (volatile int)a;
Isn't it the contents of a that's volatile, i.e. it's value can change
invisibly to the compiler, and that's why you want to force a read from
memory? Why do you need the "*(volatile int *)&" construct?
-Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
On Wed, 15 Aug 2007, Satyam Sharma wrote:
(C)
$ cat tp3.c
int a;
void func(void)
{
*(volatile int *)a = 10;
*(volatile int *)a = 20;
}
$ gcc -Os -S tp3.c
$ cat tp3.s
...
movl$10, a
movl$20, a
...
I'm curious about one minor tangential point. Why, instead of:
b = *(volatile int *)a;
why can't this just be expressed as:
b = (volatile int)a;
Isn't it the contents of a that's volatile, i.e. it's value can change
invisibly to the compiler, and that's why you want to force a read from
memory? Why do you need the *(volatile int *) construct?
-Bill
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] New firewire stack
On Thu, 03 May 2007, Kristian Høgsberg wrote: > Adrian Bunk wrote: > >> | An advantage of changing the names is that they are now prefixed. > >> > >> Is the opportunity to clean up module names compelling enough, vs. (the > >> wish for) minimized trouble with scripts which refer to module names? > >> ... > > > > How big is the trouble actually? > > Exactly. In Fedora we've just added a fw-sbp2 case to mkinitrd, it's only a > couple of lines of extra shell code: > > elif [ "$modName" = "fw-sbp2" ]; then > findmodule fw-core > findmodule fw-ohci > modName="fw-sbp2" > > and that's the extent of the changes. The sbp2 case for the old drivers is > still in there and in the end mkinitrd works with either stack. > > Kristian I also think both stacks should be provided in the mainline kernel, preferably in their own separate directories. I still need the old stack for dv1394, which isn't available in the new stack. But if the new stack is also there, I might be motivated for example to try out the new sbp2 module, to see how well it works and how it compares in performance to the old sbp2 module. If it's not there, I'm probably not going to go out of my way to download it from the net, since my existing setup is working just fine for me. -Bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] New firewire stack
On Thu, 03 May 2007, Kristian Høgsberg wrote: Adrian Bunk wrote: | An advantage of changing the names is that they are now prefixed. Is the opportunity to clean up module names compelling enough, vs. (the wish for) minimized trouble with scripts which refer to module names? ... How big is the trouble actually? Exactly. In Fedora we've just added a fw-sbp2 case to mkinitrd, it's only a couple of lines of extra shell code: elif [ $modName = fw-sbp2 ]; then findmodule fw-core findmodule fw-ohci modName=fw-sbp2 and that's the extent of the changes. The sbp2 case for the old drivers is still in there and in the end mkinitrd works with either stack. Kristian I also think both stacks should be provided in the mainline kernel, preferably in their own separate directories. I still need the old stack for dv1394, which isn't available in the new stack. But if the new stack is also there, I might be motivated for example to try out the new sbp2 module, to see how well it works and how it compares in performance to the old sbp2 module. If it's not there, I'm probably not going to go out of my way to download it from the net, since my existing setup is working just fine for me. -Bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
