* [PATCH 0/3] net: Add ftracer to help optimize process scheduling based on incomming frame allocations
From: Neil Horman @ 2009-08-07 20:21 UTC (permalink / raw)
To: netdev; +Cc: davem, rostedt, nhorman
Hey all-
I put out an RFC about this awhile ago and didn't get any loud screams,
so I've gone ahead and implemented it
Currently, our network infrastructure allows net device drivers to
allocate skbs based on the the numa node the device itself is local to. This of
course cuts down on cross numa chatter when the device is DMA-ing network
traffic to the driver. Unfortuantely no such corresponding infrastrucuture
exists at the process level. The scheduler has no insight into the numa
locality of incomming data packets for a given process (and arguably it
shouldn't), and so there is every chance that a process will run on a different
numa node than the packets that its receiving lives on, creating cross numa node
traffic.
This patch aims to provide userspace with the opportunity to optimize
that scheduling. It consists of a tracepoint and an ftrace module which exports
a history of the packets each process receives, along with the numa node each
packet was received on, as well as the numa node the process was running on when
it copied the buffer to user space. With this information, exported via the
ftrace infrastructure to user space, a sysadim can identify high prirority
processes, and optimize their scheduling so that they are more likely to run on
the same node that they are primarily receiving data on, thereby cutting down
cross numa node traffic.
Tested by me, working well, applies against the head of the net-next tree
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* RE: [Bridge] [PATCH] macvlan: add tap device backend
From: david @ 2009-08-07 20:17 UTC (permalink / raw)
To: Fischer, Anna
Cc: Stephen Hemminger, Paul Congdon (UC Davis), drobbins@funtoo.org,
'Arnd Bergmann', herbert@gondor.apana.org.au,
mst@redhat.com, netdev@vger.kernel.org,
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
ogerlitz@voltaire.com, evb@yahoogroups.com, davem@davemloft.net
In-Reply-To: <0199E0D51A61344794750DC57738F58E6D6A6CD7FE@GVW1118EXC.americas.hpqcorp.net>
On Fri, 7 Aug 2009, Fischer, Anna wrote:
> Subject: RE: [Bridge] [PATCH] macvlan: add tap device backend
>
>> Subject: Re: [Bridge] [PATCH] macvlan: add tap device backend
>>
>> On Fri, 7 Aug 2009 12:10:07 -0700
>> "Paul Congdon \(UC Davis\)" <ptcongdon@ucdavis.edu> wrote:
>>
>>> Responding to Daniel's questions...
>>>
>>>> I have some general questions about the intended use and benefits
>> of
>>>> VEPA, from an IT perspective:
>>>>
>>>> In which virtual machine setups and technologies do you forsee this
>>>> interface being used?
>>>
>>> The benefit of VEPA is the coordination and unification with the
>> external network switch. So, in environments where you are
>> needing/wanting your feature rich, wire speed, external network device
>> (firewall/switch/IPS/content-filter) to provide consistent policy
>> enforcement, and you want your VMs traffic to be subject to that
>> enforcement, you will want their traffic directed externally. Perhaps
>> you have some VMs that are on a DMZ or clustering an application or
>> implementing a multi-tier application where you would normally place a
>> firewall in-between the tiers.
>>
>> I do have to raise the point that Linux is perfectly capable of keeping
>> up without
>> the need of an external switch. Whether you want policy external or
>> internal is
>> a architecture decision that should not be driven by mis-information
>> about performance.
>
> VEPA is not only about enabling faster packet processing (like firewall/switch/IPS/content-filter etc) by doing this on the external switch.
>
> Due to rather low performance of software-based I/O virtualization approaches a lot of effort has recently been going into hardware-based implementations of virtual network interfaces like SRIOV NICs provide. Without VEPA, such a NIC would have to implement sophisticated virtual switching capabilities. VEPA however is very simple and therefore perfectly suited for a hardware-based implementation. So in the future, it will give you direct I/O like performance and all the capabilities your adjacent switch provides.
>
the performance overhead isn't from switching the packets, it's from
running the firewall/IDS/etc software on the same system.
with VEPA the communications from one VM to another VM running on the same
host will be forced to go out the interface to the datacenter switching
fabric. The overall performance of the network link will be slightly
slower, but it allows for other devices to be inserted into the path.
this is something that I would want available if I were to start using VMs
for things. I don't want to have to duplicate my IDS/firewalling functions
within each host system as well as having them as part of the switching
fabric.
David Lang
^ permalink raw reply
* Re: [PATCH 2/7 v3] initdev:kernel:USB init device discovery notification
From: Alan Jenkins @ 2009-08-07 20:09 UTC (permalink / raw)
To: David VomLehn
Cc: Alan Stern, linux-kernel, akpm, linux-usb, greg, linux-scsi,
netdev, arjan
In-Reply-To: <20090807174209.GB30450@cuplxvomd02.corp.sa.net>
David VomLehn wrote:
> On Fri, Aug 07, 2009 at 06:17:51PM +0100, Alan Jenkins wrote:
>
>> On 8/7/09, Alan Stern <stern@rowland.harvard.edu> wrote:
>>
>>> On Fri, 7 Aug 2009, Alan Jenkins wrote:
>>>
>>>
>>>>> +/* The mask of possible USB boot devices depends on what drivers and
>>>>> + * options have been configured into the kernel. There are too many
>>>>> + * USB network config options to list here, so just assume it is always
>>>>> + * possible to have a USB network device.
>>>>> + */
>>>>>
>>>> That could be fixed though. Make the "USB Network Adaptors" menu into
>>>> an option.
> I remember thinking about this and seem to recall that Alan Stern and I
> tossed this idea around, but didn't act on it. Such a thing holds potential
> for avoiding an unnecessary delay during boot. Whether it actually makes
> things faster in a given configuration will depend on that configuration's
> critical path, but I would welcome such a patch on the basis that it's
> unlikely to hurt and could improve boot times in some circumstances.
>
Bother, I see why this doesn't work now. There are all the USB
*wireless* network drivers outside the menu.
Thanks anyway
Alan
^ permalink raw reply
* RE: [Bridge] [PATCH] macvlan: add tap device backend
From: Paul Congdon (UC Davis) @ 2009-08-07 19:47 UTC (permalink / raw)
To: 'Stephen Hemminger'
Cc: drobbins, 'Fischer, Anna', 'Arnd Bergmann',
herbert, mst, netdev, bridge, linux-kernel, ogerlitz, evb, davem
In-Reply-To: <20090807123554.7c2bc27c@nehalam>
>
> I do have to raise the point that Linux is perfectly capable of keeping
> up without
> the need of an external switch. Whether you want policy external or
> internal is
> a architecture decision that should not be driven by mis-information
> about performance.
No argument here. I agree that you can do a lot in Linux. It is, as you
say, an architecture decision, that can be enabled with this addition mode
of operation. Without the mode of forcing things external, however, you
would always need to put this function internal or play games with VLANs
overlapping to get traffic to forward the way you want it.
Paul
^ permalink raw reply
* Re: [evb] Re: [PATCH][RFC] net/bridge: add basic VEPA support
From: Paul Congdon (UC Davis) @ 2009-08-07 19:44 UTC (permalink / raw)
To: evb, 'Stephen Hemminger'
Cc: 'Fischer, Anna', netdev, bridge, linux-kernel,
virtualization, 'Or Gerlitz', adobriyan, davem
In-Reply-To: <200908071329.44437.arnd@arndb.de>
[-- Attachment #1.1: Type: text/plain, Size: 862 bytes --]
Arnd,
I don't think your scheme works too well because broadcast packet coming
from other interfaces on br0 would get replicated and sent across the wire
to ethB multiple times.
Paul
That way you should be able to do something
like:
Host A Host B
/- nalvcam0 -\ /- macvlan0 - 192.168.1.1
br0 -| |- ethA === ethB -|
\- nalvcam1 -/ \- macvlan1 - 192.168.1.2
Now assuming that macvlan0 and macvlan1 are in different
network namespaces or belong to different KVM guests, these
guests would be able to communicate with each other through
the bridge on host A, which can set the policy (using ebtables)
for this communication and get interface statistics on its
nalvcam interfaces. Also, instead of having the br0, Host A could
assign an IP addresses to the two nalvcam interfaces that host
B has, and use IP forwarding between the guests of host B.
[-- Attachment #1.2: Type: text/html, Size: 9293 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Bridge mailing list
Bridge@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/bridge
^ permalink raw reply
* RE: [Bridge] [PATCH] macvlan: add tap device backend
From: Fischer, Anna @ 2009-08-07 19:44 UTC (permalink / raw)
To: Stephen Hemminger, Paul Congdon (UC Davis)
Cc: drobbins@funtoo.org, 'Paul Congdon (UC Davis)',
'Arnd Bergmann', herbert@gondor.apana.org.au,
mst@redhat.com, netdev@vger.kernel.org,
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
ogerlitz@voltaire.com, evb@yahoogroups.com, davem@davemloft.net
In-Reply-To: <20090807123554.7c2bc27c@nehalam>
> Subject: Re: [Bridge] [PATCH] macvlan: add tap device backend
>
> On Fri, 7 Aug 2009 12:10:07 -0700
> "Paul Congdon \(UC Davis\)" <ptcongdon@ucdavis.edu> wrote:
>
> > Responding to Daniel's questions...
> >
> > > I have some general questions about the intended use and benefits
> of
> > > VEPA, from an IT perspective:
> > >
> > > In which virtual machine setups and technologies do you forsee this
> > > interface being used?
> >
> > The benefit of VEPA is the coordination and unification with the
> external network switch. So, in environments where you are
> needing/wanting your feature rich, wire speed, external network device
> (firewall/switch/IPS/content-filter) to provide consistent policy
> enforcement, and you want your VMs traffic to be subject to that
> enforcement, you will want their traffic directed externally. Perhaps
> you have some VMs that are on a DMZ or clustering an application or
> implementing a multi-tier application where you would normally place a
> firewall in-between the tiers.
>
> I do have to raise the point that Linux is perfectly capable of keeping
> up without
> the need of an external switch. Whether you want policy external or
> internal is
> a architecture decision that should not be driven by mis-information
> about performance.
VEPA is not only about enabling faster packet processing (like firewall/switch/IPS/content-filter etc) by doing this on the external switch.
Due to rather low performance of software-based I/O virtualization approaches a lot of effort has recently been going into hardware-based implementations of virtual network interfaces like SRIOV NICs provide. Without VEPA, such a NIC would have to implement sophisticated virtual switching capabilities. VEPA however is very simple and therefore perfectly suited for a hardware-based implementation. So in the future, it will give you direct I/O like performance and all the capabilities your adjacent switch provides.
Anna
^ permalink raw reply
* Re: [Bridge] [PATCH] macvlan: add tap device backend
From: Stephen Hemminger @ 2009-08-07 19:35 UTC (permalink / raw)
To: Paul Congdon (UC Davis)
Cc: drobbins, 'Paul Congdon (UC Davis)',
'Fischer, Anna', 'Arnd Bergmann', herbert, mst,
netdev, bridge, linux-kernel, ogerlitz, evb, davem
In-Reply-To: <004f01ca1792$b24a7a90$16df6fb0$@edu>
On Fri, 7 Aug 2009 12:10:07 -0700
"Paul Congdon \(UC Davis\)" <ptcongdon@ucdavis.edu> wrote:
> Responding to Daniel's questions...
>
> > I have some general questions about the intended use and benefits of
> > VEPA, from an IT perspective:
> >
> > In which virtual machine setups and technologies do you forsee this
> > interface being used?
>
> The benefit of VEPA is the coordination and unification with the external network switch. So, in environments where you are needing/wanting your feature rich, wire speed, external network device (firewall/switch/IPS/content-filter) to provide consistent policy enforcement, and you want your VMs traffic to be subject to that enforcement, you will want their traffic directed externally. Perhaps you have some VMs that are on a DMZ or clustering an application or implementing a multi-tier application where you would normally place a firewall in-between the tiers.
I do have to raise the point that Linux is perfectly capable of keeping up without
the need of an external switch. Whether you want policy external or internal is
a architecture decision that should not be driven by mis-information about performance.
^ permalink raw reply
* RE: [Bridge] [PATCH] macvlan: add tap device backend
From: Paul Congdon (UC Davis) @ 2009-08-07 19:10 UTC (permalink / raw)
To: drobbins
Cc: 'Paul Congdon (UC Davis)', 'Fischer, Anna',
'Arnd Bergmann', herbert, mst, netdev, bridge,
linux-kernel, ogerlitz, evb, davem
In-Reply-To: <0199E0D51A61344794750DC57738F58E6D6A6CD7F6@GVW1118EXC.americas.hpqcorp.net>
Responding to Daniel's questions...
> I have some general questions about the intended use and benefits of
> VEPA, from an IT perspective:
>
> In which virtual machine setups and technologies do you forsee this
> interface being used?
The benefit of VEPA is the coordination and unification with the external network switch. So, in environments where you are needing/wanting your feature rich, wire speed, external network device (firewall/switch/IPS/content-filter) to provide consistent policy enforcement, and you want your VMs traffic to be subject to that enforcement, you will want their traffic directed externally. Perhaps you have some VMs that are on a DMZ or clustering an application or implementing a multi-tier application where you would normally place a firewall in-between the tiers.
> Is this new interface to be used within a virtual machine or
> container, on the master node, or both?
It is really an interface to a new type of virtual switch. When you create virtual network, I would imagine it being a new mode of operation (bridge, NAT, VEPA, etc).
> What interface(s) would need to be configured for a single virtual
> machine to use VEPA to access the network?
It would be the same as if that machine were configure to use a bridge to access the network, but the bridge mode would be different.
> What are the current flexibility, security or performance limitations
> of tun/tap and bridge that make this new interface necessary or
> beneficial?
If you have VMs that will be communicating with one another on the same physical machine, and you want their traffic to be exposed to an in-line network device such as a application firewall/IPS/content-filter (without this feature) you will have to have this device co-located within the same physical server. This will use up CPU cycles that you presumable purchased to run applications, it will require a lot of consistent configuration on all physical machines, it could invoke potentially a lot of software licensing, additional cost, etc.. Everything would need to be replicated on each physical machine. With the VEPA capability, you can leverage all this functionality in an external network device and have it managed and configured in one place. The external implementation is likely a
higher performance, silicon based implementation. It should make it easier to migrate machines from one physical server to another and maintain the same network policy enforcement.
> Is this new interface useful at all for VPN solutions or is it
> *specifically* targeted for connecting virtual machines to the
> network?
I'm not sure I see the benefit for VPN solutions, but I'd have to understand the deployment scenario better. Certainly this is targeting connecting VMs to the adjacent physical LAN.
> Is this essentially a bridge with layer-2 isolation for the virtual
> machine interfaces built-in? If isolation is provided, what mechanism
> is used to accomplish this, and how secure is it?
That might be an over simplification, but you can achieve layer-2 isolation if you connect to a standard external switch. If that switch has 'hairpin' forwarding, then the VMs can talk at L2, but their traffic is forced through the bridge. If that bridge is a security device (e.g. firewall), then their traffic is exposed to that.
The isolation in the outbound direction is created by the way frames are forwarded. They are simply dropped on the wire, so no VMs can talk directly to one another without their traffic first going external. In the inbound direction, the isolation is created using the forwarding table.
> Does VEPA look like a regular ethernet interface (eth0) on the virtual
> machine side?
Yes
> Are there any associated user-space tools required for configuring a
> VEPA?
>
The standard brctl utility has been augmented to enable/disable the capability.
> Do you have any HOWTO-style documentation that would demonstrate how
> this interface would be used in production? Or a FAQ?
>
None yet.
> This seems like a very interesting effort but I don't quite have a
> good grasp of VEPA's benefits and limitations -- I imagine that others
> are in the same boat too.
>
There are some seminar slides available on the IEEE 802.1 web-site and elsewhere. The patch had a reference to a seminar, but here is another one you might find helpful:
http://www.internet2.edu/presentations/jt2009jul/20090719-congdon.pdf
I'm happy to try to explain further...
Paul
^ permalink raw reply
* RE: [PATCH][RFC] net/bridge: add basic VEPA support
From: Paul Congdon (UC Davis) @ 2009-08-07 18:58 UTC (permalink / raw)
To: 'Stephen Hemminger', 'Fischer, Anna'
Cc: bridge, linux-kernel, netdev, virtualization, evb, davem, kaber,
adobriyan, 'Arnd Bergmann'
In-Reply-To: <20090806210002.75beb7c6@nehalam>
>
> After reading more about this, I am not convinced this should be part
> of the bridge code. The bridge code really consists of two parts:
> forwarding table and optional spanning tree. Well the VEPA code short
> circuits both of these; it can't imagine it working with STP turned
> on. The only part of bridge code that really gets used by this are the
> receive packet hooks and the crufty old API.
>
> So instead of adding more stuff to existing bridge code, why not have
> a new driver for just VEPA. You could do it with a simple version of
> macvlan type driver.
Stephen,
Thanks for your comments and questions. We do believe the bridge code is
the right place for this, so I'd like to embellish on that a bit more to
help persuade you. Sorry for the long winded response, but here are some
thoughts:
- First and foremost, VEPA is going to be a standard addition to the IEEE
802.1Q specification. The working group agreed at the last meeting to
pursue a project to augment the bridge standard with hairpin mode (aka
reflective relay) and a remote filtering service (VEPA). See for details:
http://www.ieee802.org/1/files/public/docs2009/new-evb-congdon-evbPar5C-0709
-v01.pdf
- The VEPA functionality was really a pretty small change to the code with
low risk and wouldn't seem to warrant an entire new driver or module.
- There are good use cases where VMs will want to have some of their
interfaces attached to bridges and others to bridges operating in VEPA mode.
In other words, we see simultaneous operation of the bridge code and VEPA
occurring, so having as much of the underlying code as common as possible
would seem to be beneficial.
- By augmenting the bridge code with VEPA there is a great amount of re-use
achieved. It works wherever the bridge code works and doesn't need anything
special to support KVM, XEN, and all the hooks, etc...
- The hardware vendors building SR-IOV NICs with embedded switches will be
adding VEPA mode, so by keeping the bridge module in sync would be
consistent with this trend and direction. It will be possible to extend the
hardware implementations by cascading a software bridge and/or VEPA, so
being in sync with the architecture would make this more consistent.
- The forwarding table is still needed and used on inbound traffic to
deliver frames to the correct virtual interfaces and to filter any reflected
frames. A new driver would have to basically implement an equivalent
forwarding table anyway. As I understand the current macvlan type driver,
it wouldn't filter multicast frames properly without such a table.
- It seems the hairpin mode would be needed in the bridge module whether
VEPA was added to the bridge module or a new driver. Having the associated
changes together in the same code could aid in understanding and deployment.
As I understand the macvlan code, it currently doesn't allow two VMs on the
same machine to communicate with one another. I could imagine a hairpin
mode on the adjacent bridge making this possible, but the macvlan code would
need to be updated to filter reflected frames so a source did not receive
his own packet. I could imagine this being done as well, but to also
support selective multicast usage, something similar to the bridge
forwarding table would be needed. I think putting VEPA into a new driver
would cause you to implement many things the bridge code already supports.
Given that we expect the bridge standard to ultimately include VEPA, and the
new functions are basic forwarding operations, it seems to make most sense
to keep this consistent with the bridge module.
Paul
^ permalink raw reply
* pull request: wireless-2.6 2009-08-07
From: John W. Linville @ 2009-08-07 18:39 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here are a few more late-comers intended for 2.6.31. They are basically
simple one-liners (or might-as-well-be-one-liners), most fixing potential
security or crash issues or avoiding potentially obscure bugs.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/
---
The following changes since commit 0bf52b981770cbf006323bab5177f2858a196766:
Ingo Molnar (1):
net: Fix spinlock use in alloc_netdev_mq()
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Bob Dunlop (1):
libertas: correct packing of rxpd structure
Lennert Buytenhek (5):
mwl8k: fix NULL pointer dereference on receive out-of-memory
mwl8k: add various missing GET_HW_SPEC endian conversions
mwl8k: call pci_unmap_single() before accessing command structure again
mwl8k: prevent crash in ->configure_filter() if no interface was added
mwl8k: prevent module unload hang
Zhu Yi (1):
ipw2x00: Write outside array bounds
drivers/net/wireless/ipw2x00/ipw2200.c | 2 +-
drivers/net/wireless/libertas/hostcmd.h | 4 ++--
drivers/net/wireless/mwl8k.c | 31 +++++++++++++++++++------------
3 files changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index 44c29b3..6dcac73 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -6226,7 +6226,7 @@ static void ipw_add_scan_channels(struct ipw_priv *priv,
};
u8 channel;
- while (channel_index < IPW_SCAN_CHANNELS) {
+ while (channel_index < IPW_SCAN_CHANNELS - 1) {
channel =
priv->speed_scan[priv->speed_scan_pos];
if (channel == 0) {
diff --git a/drivers/net/wireless/libertas/hostcmd.h b/drivers/net/wireless/libertas/hostcmd.h
index 0a2e291..c8a1998 100644
--- a/drivers/net/wireless/libertas/hostcmd.h
+++ b/drivers/net/wireless/libertas/hostcmd.h
@@ -56,8 +56,8 @@ struct rxpd {
u8 bss_type;
/* BSS number */
u8 bss_num;
- } bss;
- } u;
+ } __attribute__ ((packed)) bss;
+ } __attribute__ ((packed)) u;
/* SNR */
u8 snr;
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index a263d5c..83967af 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -261,7 +261,7 @@ struct mwl8k_vif {
*/
};
-#define MWL8K_VIF(_vif) (struct mwl8k_vif *)(&((_vif)->drv_priv))
+#define MWL8K_VIF(_vif) ((struct mwl8k_vif *)&((_vif)->drv_priv))
static const struct ieee80211_channel mwl8k_channels[] = {
{ .center_freq = 2412, .hw_value = 1, },
@@ -1012,6 +1012,8 @@ static int rxq_process(struct ieee80211_hw *hw, int index, int limit)
rmb();
skb = rxq->rx_skb[rxq->rx_head];
+ if (skb == NULL)
+ break;
rxq->rx_skb[rxq->rx_head] = NULL;
rxq->rx_head = (rxq->rx_head + 1) % MWL8K_RX_DESCS;
@@ -1591,6 +1593,9 @@ static int mwl8k_post_cmd(struct ieee80211_hw *hw, struct mwl8k_cmd_pkt *cmd)
timeout = wait_for_completion_timeout(&cmd_wait,
msecs_to_jiffies(MWL8K_CMD_TIMEOUT_MS));
+ pci_unmap_single(priv->pdev, dma_addr, dma_size,
+ PCI_DMA_BIDIRECTIONAL);
+
result = &cmd->result;
if (!timeout) {
spin_lock_irq(&priv->fw_lock);
@@ -1610,8 +1615,6 @@ static int mwl8k_post_cmd(struct ieee80211_hw *hw, struct mwl8k_cmd_pkt *cmd)
*result);
}
- pci_unmap_single(priv->pdev, dma_addr, dma_size,
- PCI_DMA_BIDIRECTIONAL);
return rc;
}
@@ -1654,18 +1657,18 @@ static int mwl8k_cmd_get_hw_spec(struct ieee80211_hw *hw)
memset(cmd->perm_addr, 0xff, sizeof(cmd->perm_addr));
cmd->ps_cookie = cpu_to_le32(priv->cookie_dma);
cmd->rx_queue_ptr = cpu_to_le32(priv->rxq[0].rx_desc_dma);
- cmd->num_tx_queues = MWL8K_TX_QUEUES;
+ cmd->num_tx_queues = cpu_to_le32(MWL8K_TX_QUEUES);
for (i = 0; i < MWL8K_TX_QUEUES; i++)
cmd->tx_queue_ptrs[i] = cpu_to_le32(priv->txq[i].tx_desc_dma);
- cmd->num_tx_desc_per_queue = MWL8K_TX_DESCS;
- cmd->total_rx_desc = MWL8K_RX_DESCS;
+ cmd->num_tx_desc_per_queue = cpu_to_le32(MWL8K_TX_DESCS);
+ cmd->total_rx_desc = cpu_to_le32(MWL8K_RX_DESCS);
rc = mwl8k_post_cmd(hw, &cmd->header);
if (!rc) {
SET_IEEE80211_PERM_ADDR(hw, cmd->perm_addr);
priv->num_mcaddrs = le16_to_cpu(cmd->num_mcaddrs);
- priv->fw_rev = cmd->fw_rev;
+ priv->fw_rev = le32_to_cpu(cmd->fw_rev);
priv->hw_rev = cmd->hw_rev;
priv->region_code = le16_to_cpu(cmd->region_code);
}
@@ -3216,15 +3219,19 @@ static int mwl8k_configure_filter_wt(struct work_struct *wt)
struct dev_addr_list *mclist = worker->mclist;
struct mwl8k_priv *priv = hw->priv;
- struct mwl8k_vif *mv_vif;
int rc = 0;
if (changed_flags & FIF_BCN_PRBRESP_PROMISC) {
if (*total_flags & FIF_BCN_PRBRESP_PROMISC)
rc = mwl8k_cmd_set_pre_scan(hw);
else {
- mv_vif = MWL8K_VIF(priv->vif);
- rc = mwl8k_cmd_set_post_scan(hw, mv_vif->bssid);
+ u8 *bssid;
+
+ bssid = "\x00\x00\x00\x00\x00\x00";
+ if (priv->vif != NULL)
+ bssid = MWL8K_VIF(priv->vif)->bssid;
+
+ rc = mwl8k_cmd_set_post_scan(hw, bssid);
}
}
@@ -3726,6 +3733,8 @@ static void __devexit mwl8k_remove(struct pci_dev *pdev)
ieee80211_stop_queues(hw);
+ ieee80211_unregister_hw(hw);
+
/* Remove tx reclaim tasklet */
tasklet_kill(&priv->tx_reclaim_task);
@@ -3739,8 +3748,6 @@ static void __devexit mwl8k_remove(struct pci_dev *pdev)
for (i = 0; i < MWL8K_TX_QUEUES; i++)
mwl8k_txq_reclaim(hw, i, 1);
- ieee80211_unregister_hw(hw);
-
for (i = 0; i < MWL8K_TX_QUEUES; i++)
mwl8k_txq_deinit(hw, i);
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH 4/7] vbus-proxy: add a pci-to-vbus bridge
From: Gregory Haskins @ 2009-08-07 18:25 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: Arnd Bergmann, alacrityvm-devel, linux-kernel, netdev
In-Reply-To: <20090807155500.GB12561@ovro.caltech.edu>
[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]
Ira W. Snyder wrote:
<big snip>
> With my powerpc hardware, it should be easily possible to have at least
> 6 devices, each with two virtqueues, one for tx and one for rx. (The
> limit is caused by the amount of distinct kick() events I can generate.)
> This could allow many combinations of devices, such as:
>
> * 1 virtio-net, 1 virtio-console
> * 3 virtio-net, 2 virtio-console
> * 6 virtio-net
> * etc.
Note that the vbus "connector" design abstract details such as kick
events, so you are not limited by the number of physical interrupts of
your hardware, per se.
You can actually have an arbitrary width namespace for your virtqueues
running over a single interrupt, if you were so inclined. (Note you can
also have a 1:1 with interrupts if you like, too)
If you look at the design of the vbus-pcibridge connector, it actually
aggregates the entire namespace into between 1 and 8 interrupts
(depending on availability, and separated by priority level). If
multiple vectors are not available, the entire protocol can fallback to
run over a single vector when necessary.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: [PATCH 0/7] AlacrityVM guest drivers
From: Gregory Haskins @ 2009-08-07 18:04 UTC (permalink / raw)
To: Anthony Liguori
Cc: Michael S. Tsirkin, Gregory Haskins, linux-kernel,
alacrityvm-devel, netdev, kvm
In-Reply-To: <4A7C4C50.5040503@codemonkey.ws>
[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]
Anthony Liguori wrote:
> Gregory Haskins wrote:
>> That said, note that the graphs were from earlier kernel runs (2.6.28,
>> 29-rc8). The most recent data I can find that I published is for
>> 2.6.29, announced with the vbus-v3 release back in April:
>>
>> http://lkml.org/lkml/2009/4/21/408
>>
>> In it, the virtio-net throughput numbers are substantially higher and
>> possibly more in line with your expectations (4.5gb/s) (though notably
>> still lagging venet, which weighed in at 5.6gb/s).
>>
>
> Okay, that makes more sense. Would be nice to update the graphs as they
> make virtio look really, really bad :-)
Yeah, they are certainly ripe for an update. (Note that I was
unilaterally stale on venet numbers, too) ;)
>
>> Generally, I find that the virtio-net exhibits non-deterministic results
>> from release to release. I suspect (as we have discussed) the
>> tx-mitigation scheme. Some releases buffer the daylights out of the
>> stream, and virtio gets close(r) throughput (e.g. 4.5g vs 5.8g, but
>> absolutely terrible latency (4000us vs 65us). Other releases it seems
>> to operate with more of a compromise (1.3gb/s vs 3.8gb/s, but 350us vs
>> 85us).
>>
>
> Are you using kvm modules or a new kernel?
I just build the entire kernel from git.
> There was some timer
> infrastructure changes around 28/29 and it's possible that the system
> your on is now detecting an hpet which will result in a better time
> source. That could have an affect on mitigation.
Yeah, I suspect you are right. I always kept the .config and machine
constant, but I *do* bounce around kernel versions so perhaps I got
hosed by a make-oldconfig cycle somewhere along the way.
>
>> If there is another patch-series/tree I should be using for comparison,
>> please point me at it.
>>
>
> No, I think it's fair to look at upstream Linux. Looking at the latest
> bits would be nice though because there are some virtio friendly changes
> recently like MSI-x and GRO.
Yeah, I will definitely include kvm.git in addition to whatever is
current from Linus. I already have adopted using the latest
qemu-kvm.git into my workflow.
Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* [PATCH] yellowfin: Fix buffer underrun after dev_alloc_skb() failure
From: Roel Kluin @ 2009-08-07 17:57 UTC (permalink / raw)
To: netdev, Andrew Morton, David S. Miller
When dev_alloc_skb fails in the first iteration, a buffer underrun occurs.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Is this the best way to fix this? Untested, please review.
diff --git a/drivers/net/yellowfin.c b/drivers/net/yellowfin.c
index a075801..a82ac32 100644
--- a/drivers/net/yellowfin.c
+++ b/drivers/net/yellowfin.c
@@ -728,7 +728,7 @@ static void yellowfin_tx_timeout(struct net_device *dev)
static void yellowfin_init_ring(struct net_device *dev)
{
struct yellowfin_private *yp = netdev_priv(dev);
- int i;
+ int i, j;
yp->tx_full = 0;
yp->cur_rx = yp->cur_tx = 0;
@@ -753,6 +753,11 @@ static void yellowfin_init_ring(struct net_device *dev)
yp->rx_ring[i].addr = cpu_to_le32(pci_map_single(yp->pci_dev,
skb->data, yp->rx_buf_sz, PCI_DMA_FROMDEVICE));
}
+ if (i != RX_RING_SIZE) {
+ for (j = 0; j < i; j++)
+ dev_kfree_skb(yp->rx_skbuff[j]);
+ return;
+ }
yp->rx_ring[i-1].dbdma_cmd = cpu_to_le32(CMD_STOP);
yp->dirty_rx = (unsigned int)(i - RX_RING_SIZE);
^ permalink raw reply related
* [net-2.6 PATCH 2/2] e1000e: fix potential NVM corruption on ICH9 with 8K bank size
From: Jeff Kirsher @ 2009-08-07 17:41 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Bruce Allan, Jeff Kirsher
In-Reply-To: <20090807174136.31114.96240.stgit@localhost.localdomain>
From: Bruce Allan <bruce.w.allan@intel.com>
The bank offset was being incorrectly calculated on ICH9 parts with a bank
size of 8K (instead of the more common 4K bank) which would cause any NVM
writes to be done on the wrong address after switching from bank 1 to bank
0. Additionally, assume we are meant to use bank 0 if a valid bank is not
detected, and remove the unnecessary acquisition of the SW/FW/HW semaphore
when writing to the shadow ram version of the NVM image.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/ich8lan.c | 50 ++++++++++--------------------------------
1 files changed, 12 insertions(+), 38 deletions(-)
diff --git a/drivers/net/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c
index dd61e7e..99df2ab 100644
--- a/drivers/net/e1000e/ich8lan.c
+++ b/drivers/net/e1000e/ich8lan.c
@@ -338,10 +338,7 @@ static s32 e1000_init_nvm_params_ich8lan(struct e1000_hw *hw)
{
struct e1000_nvm_info *nvm = &hw->nvm;
struct e1000_dev_spec_ich8lan *dev_spec = &hw->dev_spec.ich8lan;
- union ich8_hws_flash_status hsfsts;
- u32 gfpreg;
- u32 sector_base_addr;
- u32 sector_end_addr;
+ u32 gfpreg, sector_base_addr, sector_end_addr;
u16 i;
/* Can't read flash registers if the register set isn't mapped. */
@@ -375,20 +372,6 @@ static s32 e1000_init_nvm_params_ich8lan(struct e1000_hw *hw)
/* Adjust to word count */
nvm->flash_bank_size /= sizeof(u16);
- /*
- * Make sure the flash bank size does not overwrite the 4k
- * sector ranges. We may have 64k allotted to us but we only care
- * about the first 2 4k sectors. Therefore, if we have anything less
- * than 64k set in the HSFSTS register, we will reduce the bank size
- * down to 4k and let the rest remain unused. If berasesz == 3, then
- * we are working in 64k mode. Otherwise we are not.
- */
- if (nvm->flash_bank_size > E1000_ICH8_SHADOW_RAM_WORDS) {
- hsfsts.regval = er16flash(ICH_FLASH_HSFSTS);
- if (hsfsts.hsf_status.berasesz != 3)
- nvm->flash_bank_size = E1000_ICH8_SHADOW_RAM_WORDS;
- }
-
nvm->word_size = E1000_ICH8_SHADOW_RAM_WORDS;
/* Clear shadow ram */
@@ -1324,7 +1307,7 @@ static s32 e1000_read_nvm_ich8lan(struct e1000_hw *hw, u16 offset, u16 words,
struct e1000_nvm_info *nvm = &hw->nvm;
struct e1000_dev_spec_ich8lan *dev_spec = &hw->dev_spec.ich8lan;
u32 act_offset;
- s32 ret_val;
+ s32 ret_val = 0;
u32 bank = 0;
u16 i, word;
@@ -1339,12 +1322,15 @@ static s32 e1000_read_nvm_ich8lan(struct e1000_hw *hw, u16 offset, u16 words,
goto out;
ret_val = e1000_valid_nvm_bank_detect_ich8lan(hw, &bank);
- if (ret_val)
- goto release;
+ if (ret_val) {
+ hw_dbg(hw, "Could not detect valid bank, assuming bank 0\n");
+ bank = 0;
+ }
act_offset = (bank) ? nvm->flash_bank_size : 0;
act_offset += offset;
+ ret_val = 0;
for (i = 0; i < words; i++) {
if ((dev_spec->shadow_ram) &&
(dev_spec->shadow_ram[offset+i].modified)) {
@@ -1359,7 +1345,6 @@ static s32 e1000_read_nvm_ich8lan(struct e1000_hw *hw, u16 offset, u16 words,
}
}
-release:
e1000_release_swflag_ich8lan(hw);
out:
@@ -1610,7 +1595,6 @@ static s32 e1000_write_nvm_ich8lan(struct e1000_hw *hw, u16 offset, u16 words,
{
struct e1000_nvm_info *nvm = &hw->nvm;
struct e1000_dev_spec_ich8lan *dev_spec = &hw->dev_spec.ich8lan;
- s32 ret_val;
u16 i;
if ((offset >= nvm->word_size) || (words > nvm->word_size - offset) ||
@@ -1619,17 +1603,11 @@ static s32 e1000_write_nvm_ich8lan(struct e1000_hw *hw, u16 offset, u16 words,
return -E1000_ERR_NVM;
}
- ret_val = e1000_acquire_swflag_ich8lan(hw);
- if (ret_val)
- return ret_val;
-
for (i = 0; i < words; i++) {
dev_spec->shadow_ram[offset+i].modified = 1;
dev_spec->shadow_ram[offset+i].value = data[i];
}
- e1000_release_swflag_ich8lan(hw);
-
return 0;
}
@@ -1670,8 +1648,8 @@ static s32 e1000_update_nvm_checksum_ich8lan(struct e1000_hw *hw)
*/
ret_val = e1000_valid_nvm_bank_detect_ich8lan(hw, &bank);
if (ret_val) {
- e1000_release_swflag_ich8lan(hw);
- goto out;
+ hw_dbg(hw, "Could not detect valid bank, assuming bank 0\n");
+ bank = 0;
}
if (bank == 0) {
@@ -2057,12 +2035,8 @@ static s32 e1000_erase_flash_bank_ich8lan(struct e1000_hw *hw, u32 bank)
iteration = 1;
break;
case 2:
- if (hw->mac.type == e1000_ich9lan) {
- sector_size = ICH_FLASH_SEG_SIZE_8K;
- iteration = flash_bank_size / ICH_FLASH_SEG_SIZE_8K;
- } else {
- return -E1000_ERR_NVM;
- }
+ sector_size = ICH_FLASH_SEG_SIZE_8K;
+ iteration = 1;
break;
case 3:
sector_size = ICH_FLASH_SEG_SIZE_64K;
@@ -2074,7 +2048,7 @@ static s32 e1000_erase_flash_bank_ich8lan(struct e1000_hw *hw, u32 bank)
/* Start with the base address, then add the sector offset. */
flash_linear_addr = hw->nvm.flash_base_addr;
- flash_linear_addr += (bank) ? (sector_size * iteration) : 0;
+ flash_linear_addr += (bank) ? flash_bank_size : 0;
for (j = 0; j < iteration ; j++) {
do {
^ permalink raw reply related
* Re: [PATCH 2/7 v3] initdev:kernel:USB init device discovery notification
From: David VomLehn @ 2009-08-07 17:42 UTC (permalink / raw)
To: Alan Jenkins
Cc: Alan Stern, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-usb-u79uwXL29TY76Z2rM5mHXA, greg-U8xfFu+wG4EAvxtiuMwx3w,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
arjan-wEGCiKHe2LqWVfeAwA7xHQ
In-Reply-To: <9b2b86520908071017h606e595fr4488d6ff61cb337c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Aug 07, 2009 at 06:17:51PM +0100, Alan Jenkins wrote:
> On 8/7/09, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> > On Fri, 7 Aug 2009, Alan Jenkins wrote:
> >
> >> > +/* The mask of possible USB boot devices depends on what drivers and
> >> > + * options have been configured into the kernel. There are too many
> >> > + * USB network config options to list here, so just assume it is always
> >> > + * possible to have a USB network device.
> >> > + */
> >>
> >> That could be fixed though. Make the "USB Network Adaptors" menu into
> >> an option. Then you just have e.g. "CONFIG_NETDEV_USB", plus the two
> >> class devices outside the menu (CONFIG_USB_ACM and CONFIG_USB_WDM).
>
> Oops, scratch WDM. It doesn't actually provide a network device
> (otherwise it would depend on NET).
>
> > That could be done. It might even meet with the approval of the
> > networking maintainer, independent of this patch series.
> >
> > But what if somebody adds yet another networking class driver outside
> > the menu?
>
> Hmm.
>
> Ok, how about a single (hidden) USB_HAS_NETDEV. NETDEV_USB and
> USB_ACM select USB_HAS_NETDEV.
>
> Textual juxtaposition or simple copy+paste inside class/Kconfig should
> help it get picked up. And I'd add a comment pointing the bewildered
> to the definition of usb_initdev_mask.
>
> I'll write a patch for your inspection this evening.
I remember thinking about this and seem to recall that Alan Stern and I
tossed this idea around, but didn't act on it. Such a thing holds potential
for avoiding an unnecessary delay during boot. Whether it actually makes
things faster in a given configuration will depend on that configuration's
critical path, but I would welcome such a patch on the basis that it's
unlikely to hurt and could improve boot times in some circumstances.
> Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [net-2.6 PATCH 1/2] e1000e: fix acquisition of SW/FW/HW semaphore for ICHx parts
From: Jeff Kirsher @ 2009-08-07 17:41 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Bruce Allan, Jeff Kirsher
From: Bruce Allan <bruce.w.allan@intel.com>
For ICHx parts, write the EXTCNF_CTRL.SWFLAG bit once when trying to
acquire the SW/FW/HW semaphore instead of multiple times to prevent the
hardware from having problems (especially for systems with manageability
enabled), and extend the timeout for the hardware to set the SWFLAG bit.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/ich8lan.c | 44 ++++++++++++++++++++++++++++++------------
1 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/net/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c
index d56c747..dd61e7e 100644
--- a/drivers/net/e1000e/ich8lan.c
+++ b/drivers/net/e1000e/ich8lan.c
@@ -594,8 +594,8 @@ static DEFINE_MUTEX(nvm_mutex);
**/
static s32 e1000_acquire_swflag_ich8lan(struct e1000_hw *hw)
{
- u32 extcnf_ctrl;
- u32 timeout = PHY_CFG_TIMEOUT;
+ u32 extcnf_ctrl, timeout = PHY_CFG_TIMEOUT;
+ s32 ret_val = 0;
might_sleep();
@@ -603,28 +603,46 @@ static s32 e1000_acquire_swflag_ich8lan(struct e1000_hw *hw)
while (timeout) {
extcnf_ctrl = er32(EXTCNF_CTRL);
+ if (!(extcnf_ctrl & E1000_EXTCNF_CTRL_SWFLAG))
+ break;
- if (!(extcnf_ctrl & E1000_EXTCNF_CTRL_SWFLAG)) {
- extcnf_ctrl |= E1000_EXTCNF_CTRL_SWFLAG;
- ew32(EXTCNF_CTRL, extcnf_ctrl);
+ mdelay(1);
+ timeout--;
+ }
+
+ if (!timeout) {
+ hw_dbg(hw, "SW/FW/HW has locked the resource for too long.\n");
+ ret_val = -E1000_ERR_CONFIG;
+ goto out;
+ }
+
+ timeout = PHY_CFG_TIMEOUT * 2;
+
+ extcnf_ctrl |= E1000_EXTCNF_CTRL_SWFLAG;
+ ew32(EXTCNF_CTRL, extcnf_ctrl);
+
+ while (timeout) {
+ extcnf_ctrl = er32(EXTCNF_CTRL);
+ if (extcnf_ctrl & E1000_EXTCNF_CTRL_SWFLAG)
+ break;
- extcnf_ctrl = er32(EXTCNF_CTRL);
- if (extcnf_ctrl & E1000_EXTCNF_CTRL_SWFLAG)
- break;
- }
mdelay(1);
timeout--;
}
if (!timeout) {
- hw_dbg(hw, "FW or HW has locked the resource for too long.\n");
+ hw_dbg(hw, "Failed to acquire the semaphore.\n");
extcnf_ctrl &= ~E1000_EXTCNF_CTRL_SWFLAG;
ew32(EXTCNF_CTRL, extcnf_ctrl);
- mutex_unlock(&nvm_mutex);
- return -E1000_ERR_CONFIG;
+ ret_val = -E1000_ERR_CONFIG;
+ goto out;
}
- return 0;
+out:
+ if (ret_val)
+ mutex_unlock(&nvm_mutex);
+
+ return ret_val;
}
/**
^ permalink raw reply related
* Re: [Bridge] [PATCH] macvlan: add tap device backend
From: Daniel Robbins @ 2009-08-07 17:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: netdev, Herbert Xu, Michael S. Tsirkin, Fischer, Anna, bridge,
linux-kernel, David S. Miller", Or Gerlitz,
Edge Virtual Bridging
In-Reply-To: <1249595428-21594-1-git-send-email-arnd@arndb.de>
On Thu, Aug 6, 2009 at 3:50 PM, Arnd Bergmann<arnd@arndb.de> wrote:
> This is a first prototype of a new interface into the network
> stack, to eventually replace tun/tap and the bridge driver
> in certain virtual machine setups.
I have some general questions about the intended use and benefits of
VEPA, from an IT perspective:
In which virtual machine setups and technologies do you forsee this
interface being used?
Is this new interface to be used within a virtual machine or
container, on the master node, or both?
What interface(s) would need to be configured for a single virtual
machine to use VEPA to access the network?
What are the current flexibility, security or performance limitations
of tun/tap and bridge that make this new interface necessary or
beneficial?
Is this new interface useful at all for VPN solutions or is it
*specifically* targeted for connecting virtual machines to the
network?
Is this essentially a bridge with layer-2 isolation for the virtual
machine interfaces built-in? If isolation is provided, what mechanism
is used to accomplish this, and how secure is it?
Does VEPA look like a regular ethernet interface (eth0) on the virtual
machine side?
Are there any associated user-space tools required for configuring a VEPA?
Do you have any HOWTO-style documentation that would demonstrate how
this interface would be used in production? Or a FAQ?
This seems like a very interesting effort but I don't quite have a
good grasp of VEPA's benefits and limitations -- I imagine that others
are in the same boat too.
Best Regards,
Daniel
^ permalink raw reply
* Re: [PATCH 2/7 v3] initdev:kernel:USB init device discovery notification
From: Alan Jenkins @ 2009-08-07 17:17 UTC (permalink / raw)
To: Alan Stern
Cc: David VomLehn, linux-kernel, akpm, linux-usb, greg, linux-scsi,
netdev, arjan
In-Reply-To: <Pine.LNX.4.44L0.0908071142260.3063-100000@iolanthe.rowland.org>
On 8/7/09, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 7 Aug 2009, Alan Jenkins wrote:
>
>> > +/* The mask of possible USB boot devices depends on what drivers and
>> > + * options have been configured into the kernel. There are too many
>> > + * USB network config options to list here, so just assume it is always
>> > + * possible to have a USB network device.
>> > + */
>>
>> That could be fixed though. Make the "USB Network Adaptors" menu into
>> an option. Then you just have e.g. "CONFIG_NETDEV_USB", plus the two
>> class devices outside the menu (CONFIG_USB_ACM and CONFIG_USB_WDM).
Oops, scratch WDM. It doesn't actually provide a network device
(otherwise it would depend on NET).
> That could be done. It might even meet with the approval of the
> networking maintainer, independent of this patch series.
>
> But what if somebody adds yet another networking class driver outside
> the menu?
Hmm.
Ok, how about a single (hidden) USB_HAS_NETDEV. NETDEV_USB and
USB_ACM select USB_HAS_NETDEV.
Textual juxtaposition or simple copy+paste inside class/Kconfig should
help it get picked up. And I'd add a comment pointing the bewildered
to the definition of usb_initdev_mask.
I'll write a patch for your inspection this evening.
Alan
^ permalink raw reply
* [PATCH] REPORTING-BUGS: Add get_maintainer.pl blurb
From: Joe Perches @ 2009-08-07 17:01 UTC (permalink / raw)
To: David Miller; +Cc: sposelenov, linux-kernel, Andrew Morton, netdev
In-Reply-To: <20090807.090353.191304972.davem@davemloft.net>
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/REPORTING-BUGS b/REPORTING-BUGS
index ab0c566..55a6074 100644
--- a/REPORTING-BUGS
+++ b/REPORTING-BUGS
@@ -15,7 +15,10 @@ worry too much about getting the wrong person. If you are unsure send it
to the person responsible for the code relevant to what you were doing.
If it occurs repeatably try and describe how to recreate it. That is
worth even more than the oops itself. The list of maintainers and
-mailing lists is in the MAINTAINERS file in this directory.
+mailing lists is in the MAINTAINERS file in this directory. If you
+know the file name that causes the problem you can use the following
+command in this directory to find some of the maintainers of that file:
+ perl scripts/get_maintainer.pl -f <filename>
If it is a security bug, please copy the Security Contact listed
in the MAINTAINERS file. They can help coordinate bugfix and disclosure.
^ permalink raw reply related
* [PATCH] MAINTAINERS: additional NETWORKING [GENERAL] and NETWORKING DRIVERS patterns
From: Joe Perches @ 2009-08-07 16:43 UTC (permalink / raw)
To: David Miller; +Cc: sposelenov, linux-kernel, wd, netdev, Andrew Morton
In-Reply-To: <20090807.090353.191304972.davem@davemloft.net>
On Fri, 2009-08-07 at 09:03 -0700, David Miller wrote:
> From: Sergei Poselenov <sposelenov@emcraft.com>
> > Unfortunately, received no replies, but the problem still persists.
> I guarantee you'll get more responses if you send networking bug
> reports at least CC:'d to netdev@vger.kernel.org
Perhaps this will help get cc's to the right places.
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index b1114cf..0b697a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3555,6 +3555,9 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
S: Maintained
F: net/
F: include/net/
+F: include/linux/in.h
+F: include/linux/net.h
+F: include/linux/netdevice.h
NETWORKING [IPv4/IPv6]
M: "David S. Miller" <davem@davemloft.net>
@@ -3590,6 +3593,8 @@ W: http://www.linuxfoundation.org/en/Net
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
S: Odd Fixes
F: drivers/net/
+F: include/linux/if_*
+F: include/linux/*device.h
NETXEN (1/10) GbE SUPPORT
M: Dhananjay Phadke <dhananjay@netxen.com>
^ permalink raw reply related
* Re: 3x59x-fix-pci-resource-management.patch
From: Andrew Morton @ 2009-08-07 16:14 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Steffen Klassert, netdev
In-Reply-To: <4A7C079D.8010505@ru.mvista.com>
On Fri, 07 Aug 2009 14:53:17 +0400 Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
> Hello.
>
> Andrew Morton wrote:
>
> > Guys, I seem to have been sitting on the below patch for, err, three years.
>
> > I generally do this because there's some issue which needs to be
> > addressed, but the patch didn't address it right.
>
> In this case it was different: you just wanted the patch to be verifed
> on an EISA card...
>
> On Mon, 14 Aug 2006 14:31:46 -0400
> Jeff Garzik <jgarzik@pobox.com> wrote:
>
> >> ACK, shall I apply this to netdev#upstream ?
>
> Spose so, but let's not go mainline until I've had a chance to test an
> EISA card and a cardbus card.
>
> There was several more comments from you but they all got resolved
> between you and Jeff at the time...
>
Doh, OK, thanks. My fault.
I have a cardbus card somewhere..
^ permalink raw reply
* Re: [PATCH 4/7] vbus-proxy: add a pci-to-vbus bridge
From: Ira W. Snyder @ 2009-08-07 15:55 UTC (permalink / raw)
To: Gregory Haskins; +Cc: Arnd Bergmann, alacrityvm-devel, linux-kernel, netdev
In-Reply-To: <4A7B78580200005A00051D50@sinclair.provo.novell.com>
On Thu, Aug 06, 2009 at 10:42:00PM -0600, Gregory Haskins wrote:
> >>> On 8/6/2009 at 6:57 PM, in message <200908070057.54795.arnd@arndb.de>, Arnd
> Bergmann <arnd@arndb.de> wrote:
[ big snip ]
> >> I see a few issues with that, however:
> >>
> >> 1) The virtqueue library, while a perfectly nice ring design at the metadata
> > level, does not have an API that is friendly to kernel-to-kernel communication.
> > It was designed more for frontend use to some remote backend. The IOQ
> > library on the other hand, was specifically designed to support use as
> > kernel-to-kernel (see north/south designations). So this made life easier
> > for me. To do what you propose, the eventq channel would need to terminate
> > in kernel, and I would thus be forced to deal that the potential API
> > problems.
> >
> > Well, virtqueues are not that bad for kernel-to-kernel communication, as Ira
> > mentioned
> > referring to his virtio-over-PCI driver. You can have virtqueues on both
> > sides, having
> > the host kernel create a pair of virtqueues (one in user aka guest space,
> > one in the host
> > kernel), with the host virtqueue_ops doing copy_{to,from}_user to move data
> > between them.
>
> Its been a while since I looked, so perhaps I am wrong here. I will look again.
>
> >
> > If you have that, you can actually use the same virtio_net driver in both
> > guest and
> > host kernel, just communicating over different virtio implementations.
> > Interestingly,
> > that would mean that you no longer need a separation between guest and host
> > device
> > drivers (vbus and vbus-proxy in your case) but could use the same device
> > abstraction
> > with just different transports to back the shm-signal or virtqueue.
>
> Actually, I think there are some problems with that model (such as management of the interface). virtio-net really wants to connect to a virtio-net-backend (such as the one in qemu or vbus). It wasn't designed to connect back to back like that. I think you will quickly run into problems similar to what Ira faced with virtio-over-PCI with that model.
>
Getting the virtio-net devices talking to each other over PCI was not
terribly difficult. However, the capabilities negotiation works in a
VERY awkward way. The capabilities negotiation was really designed with
a virtio-net-backend in mind. Unless I'm missing something obvious, it
is essentially broken for the case where two virtio-net's are talking to
each other.
For example, imagine the situation where you'd like the guest to get a
specific MAC address, but you do not care what MAC address the host
recieves.
Normally, you'd set struct virtio_net_config's mac[] field, and set the
VIRTIO_NET_F_MAC feature. However, when you have two virtio-net's
communicating directly, this doesn't work.
Let me explain with a quick diagram. The results described are the
values RETURNED from virtio_config_ops->get() and
virtio_config_ops->get_features() when called by the system in question.
Guest System
1) struct virtio_net_config->mac[]: 00:11:22:33:44:55
2) features: VIRTIO_NET_F_MAC
Host System
1) struct virtio_net_config->mac[]: unset
2) features: VIRTIO_NET_F_MAC unset
In this case, the feature negotiation code will not accept the
VIRTIO_NET_F_MAC feature, and both systems will generate random mac
addresses. Not the behavior we want at all.
I "fixed" the problem by ALWAYS setting a random MAC address, and ALWAYS
setting the VIRTIO_NET_F_MAC feature. By doing this, both sides always
negotiate the VIRTIO_NET_F_MAC feature.
In conclusion, the feature negotiation works fine for driver features,
such as VIRTIO_NET_MRG_RXBUF or VIRTIO_NET_F_GSO, but completely breaks
down for user-controlled features, like VIRTIO_NET_F_MAC.
I think the vbus configfs interface works great for this situation,
because it has an obvious and seperate backend. It is obvious where the
configuration information is coming from.
With my powerpc hardware, it should be easily possible to have at least
6 devices, each with two virtqueues, one for tx and one for rx. (The
limit is caused by the amount of distinct kick() events I can generate.)
This could allow many combinations of devices, such as:
* 1 virtio-net, 1 virtio-console
* 3 virtio-net, 2 virtio-console
* 6 virtio-net
* etc.
In all honesty, I don't really care so much about the management
interface for my purposes. A static configuration of devices works for
me. However, I doubt that would ever be accepted into the upstream
kernel, which is what I'm really concerned about. I hate seeing drivers
live out-of-tree.
Getting two virtio-net's talking to each other had one other major
problem: the fields in struct virtio_net_hdr are not defined with a
constant endianness. When connecting two virtio-net's running on
different machines, they may have different endianness, as in my case
between a big-endian powerpc guest and a little-endian x86 host. I'm not
confident that qemu-system-ppc, running on x86, using virtio for the
network interface, even works at all. (I have not tested it.)
Sorry that this got somewhat long winded and went a little off topic.
Ira
^ permalink raw reply
* Re: [PATCH 0/7] AlacrityVM guest drivers
From: Anthony Liguori @ 2009-08-07 15:46 UTC (permalink / raw)
To: Gregory Haskins
Cc: Michael S. Tsirkin, Gregory Haskins, linux-kernel,
alacrityvm-devel, netdev, kvm
In-Reply-To: <4A7C42C8.5050608@gmail.com>
Gregory Haskins wrote:
> That said, note that the graphs were from earlier kernel runs (2.6.28,
> 29-rc8). The most recent data I can find that I published is for
> 2.6.29, announced with the vbus-v3 release back in April:
>
> http://lkml.org/lkml/2009/4/21/408
>
> In it, the virtio-net throughput numbers are substantially higher and
> possibly more in line with your expectations (4.5gb/s) (though notably
> still lagging venet, which weighed in at 5.6gb/s).
>
Okay, that makes more sense. Would be nice to update the graphs as they
make virtio look really, really bad :-)
> Generally, I find that the virtio-net exhibits non-deterministic results
> from release to release. I suspect (as we have discussed) the
> tx-mitigation scheme. Some releases buffer the daylights out of the
> stream, and virtio gets close(r) throughput (e.g. 4.5g vs 5.8g, but
> absolutely terrible latency (4000us vs 65us). Other releases it seems
> to operate with more of a compromise (1.3gb/s vs 3.8gb/s, but 350us vs
> 85us).
>
Are you using kvm modules or a new kernel? There was some timer
infrastructure changes around 28/29 and it's possible that the system
your on is now detecting an hpet which will result in a better time
source. That could have an affect on mitigation.
> If there is another patch-series/tree I should be using for comparison,
> please point me at it.
>
No, I think it's fair to look at upstream Linux. Looking at the latest
bits would be nice though because there are some virtio friendly changes
recently like MSI-x and GRO.
Since you're using the latest vbus bits, it makes sense to compare
against the latest virtio bits.
Regards,
Anthony Liguori
^ permalink raw reply
* Re: [PATCH 2/7 v3] initdev:kernel:USB init device discovery notification
From: Alan Stern @ 2009-08-07 15:44 UTC (permalink / raw)
To: Alan Jenkins
Cc: David VomLehn, linux-kernel, akpm, linux-usb, greg, linux-scsi,
netdev, arjan
In-Reply-To: <9b2b86520908070832p2d1658b0t8b1d89d1a034bb9a@mail.gmail.com>
On Fri, 7 Aug 2009, Alan Jenkins wrote:
> > +/* The mask of possible USB boot devices depends on what drivers and
> > + * options have been configured into the kernel. There are too many
> > + * USB network config options to list here, so just assume it is always
> > + * possible to have a USB network device.
> > + */
>
> That could be fixed though. Make the "USB Network Adaptors" menu into
> an option. Then you just have e.g. "CONFIG_NETDEV_USB", plus the two
> class devices outside the menu (CONFIG_USB_ACM and CONFIG_USB_WDM).
That could be done. It might even meet with the approval of the
networking maintainer, independent of this patch series.
But what if somebody adds yet another networking class driver outside
the menu?
Alan Stern
^ permalink raw reply
* Re: [PATCH 4/7] vbus-proxy: add a pci-to-vbus bridge
From: Gregory Haskins @ 2009-08-07 15:44 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: alacrityvm-devel, Ira W. Snyder, linux-kernel, netdev
In-Reply-To: <200908071657.32858.arnd@arndb.de>
>>> On 8/7/2009 at 10:57 AM, in message <200908071657.32858.arnd@arndb.de>, Arnd
Bergmann <arnd@arndb.de> wrote:
> On Friday 07 August 2009, Gregory Haskins wrote:
>> >>> Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Thursday 06 August 2009, Gregory Haskins wrote:
>> >
>> > > 2b) I also want to collapse multiple interrupts together so as to
>> > > minimize the context switch rate (inject + EIO overhead). My design
>> > > effectively has "NAPI" for interrupt handling. This helps when the system
>
>> > > needs it the most: heavy IO.
>> >
>> > That sounds like a very useful concept in general, but this seems to be a
>> > detail of the interrupt controller implementation. If the IO-APIC cannot
>> > do what you want here, maybe we just need a paravirtual IRQ controller
>> > driver, like e.g. the PS3 has.
>>
>> Yeah, I agree this could be a function of the APIC code. Do note that I
>> mentioned this in passing to Avi a few months ago but FWIW he indicated
>> at that time that he is not interested in making the APIC PV.
>>
>> Also, I almost forgot an important one. Add:
>>
>> 2c) Interrupt prioritization. I want to be able to assign priority
>> to interrupts and handle them in priority order.
>
> I think this part of the interface has developed into the wrong direction
> because you confused two questions:
>
> 1. should you build an advanced interrupt mechanism for virtual drivers?
> 2. how should you build an advanced interrupt mechanism for virtual drivers?
>
> My guess is that when Avi said he did not want a paravirtual IO-APIC,
> he implied that the existing one is good enough (maybe Avi can clarify that
> point himself) answering question 1, while you took that as an indication
> that the code should live elsewhere instead, answering question 2.
>
> What you built with the shm-signal code is essentially a paravirtual nested
> interrupt controller by another name, and deeply integrated into a new
> bigger subsystem. I believe that this has significant disadvantages
> over the approach of making it a standard interrupt controller driver:
>
> * It completely avoids the infrastructure that we have built into Linux
> to deal with interrupts, e.g. /proc/interrupts statistics, IRQ
> balancing and CPU affinity.
>
> * It makes it impossible to quantify the value of the feature to start with,
> which could be used to answer question 1 above.
>
> * Less importantly, it does not work with any other drivers that might
> also benefit from a new interrupt controller -- if it is indeed better
> than the one we already have.
>
> Arnd <><
Hi Arnd,
I don't strongly disagree with anything you said (except for perhaps that I confused the question). I agree that the PCI-bridge effectively implements something akin to an interrupt controller. I agree that this interrupt controller, if indeed superior (I believe it is), can only benefit devices inherently behind the bridge instead of all of KVM (this in of itself doesnt bother me, as I plan on all my performance work to be based on that bus, but I digress. Also note that this is not dissimilar to other bridge+bus (think usb, scsi) operation). I agree that a potentially more ideal solution would be if we had a proper generic PV interrupt controller that exhibited similar traits as to what I describe (priority, inject+EIO overhead reduction, etc) so that all of KVM benefited.
The issue wasn't that I didn't know these things. The issue is that I have no control over whether such an intrusive change to KVM (and the guest arch code) is accepted (and at least one relevant maintainer expressed dissatisfaction (*) at the idea when proposed) Conversely, I am the maintainer of AlacrityVM, so I do have control over the bridge design. ;) Also note that this particular design decision is completely encapsulated within alacrityvm's components. IOW, I am not foisting my ideas on the entire kernel tree: If someone doesn't like what I have done, they can choose not to use alacrity and its like my ideas never existed. The important thing with this distinction is I am not changing how core linux or core kvm works in the process, only the one little piece of the world that
particularly interests me.
That said, if attitudes about some of these ideas have changed, I may be able to break that piece out and start submitting it to kvm@ as some kind of pv interrupt controller. I would only be interested in doing so if Avi et. al. express an openness to the idea...I.e.. I don't want to waste my time any more than any one elses.
Kind Regards,
-Greg
(*) I think Avi said something to the effect of "you are falling into the 'lets PV the world' trap"
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox