Johannes Berg [EMAIL PROTECTED] writes:
Our virtual devices are always associated with a piece of hardware, and
we really want them to be associated with that at all times, even when
not UP. Everything else seems like a huge complication if only because
then we can't have whoever will be
On Tue, 2007-04-10 at 00:08 -0600, Eric W. Biederman wrote:
How are you specifying which piece of hardware today? By interface name?
By wiphy index, which is just the hardware identifier we give each
802.11 device present on the system (if it uses cfg80211)
What function do your virtual
On Tuesday 10 April 2007 01:58, Dmitry Torokhov wrote:
Hi,
This is a modified version of rfkill patch that provides infrastructure
for controlling state of RF transmitters found on various cards.
Well, Andrew found bunch of issues with the patch so here is an
updated version...
--
Dmitry
Johannes Berg wrote:
Our virtual devices are always associated with a piece of hardware, and
we really want them to be associated with that at all times, even when
not UP. Everything else seems like a huge complication if only because
then we can't have whoever will be responsible for the
On Mon, Apr 09, 2007 at 04:38:18PM +0300, Avi Kivity ([EMAIL PROTECTED]) wrote:
But I don't get this we can enhance the kernel but not userspace vibe
8(
I've been waiting for network aio since ~2003. If it arrives in the
next few days, I'm all for it; much more than kvm can use it
On Mon, Apr 09, 2007 at 02:28:41PM -0700, Peter P Waskiewicz Jr ([EMAIL
PROTECTED]) wrote:
+ alloc_size = (sizeof(struct net_device_subqueue) * queue_count);
+
+ p = kzalloc(alloc_size, GFP_KERNEL);
+ if (!p) {
+ printk(KERN_ERR alloc_netdev: Unable to allocate
Evgeniy Polyakov wrote:
On Mon, Apr 09, 2007 at 04:38:18PM +0300, Avi Kivity ([EMAIL PROTECTED])
wrote:
But I don't get this we can enhance the kernel but not userspace vibe
8(
I've been waiting for network aio since ~2003. If it arrives in the
next few days, I'm all for
On Tue, Apr 10, 2007 at 11:19:52AM +0300, Avi Kivity ([EMAIL PROTECTED]) wrote:
I meant, network aio in the mainline kernel. I am aware of the various
out-of-tree implementations.
If potential users do not pay attention to initial implementaion, it is
quite hard to them to get into. But
Waskiewicz Jr, Peter P wrote:
Thanks Pat for the initial feedback. I can post a set of patches to
e1000 using the new API; I'll try to get them out asap (need to apply to
this kernel tree).
Thanks.
However, the PRIO qdisc still uses the priority in
the bands for dequeueing priority, and
On Tue, 2007-04-10 at 09:52 +0200, Patrick McHardy wrote:
Shouldn't be a problem either. Creating the device atomically also
prevents that anything else is setting them UP before they're fully
configured.
How would you do it generically then? I'm absolutely not opposed to the
idea but for now
Peter P Waskiewicz Jr wrote:
+ /* To retrieve statistics per subqueue - FOR FUTURE USE */
+ struct net_device_stats* (*get_subqueue_stats)(struct net_device *dev,
+ int queue_index);
Please no future use stuff, just add it when you
Johannes Berg wrote:
On Tue, 2007-04-10 at 09:52 +0200, Patrick McHardy wrote:
Shouldn't be a problem either. Creating the device atomically also
prevents that anything else is setting them UP before they're fully
configured.
How would you do it generically then? I'm absolutely not
On Tue, 2007-04-10 at 11:52 +0200, Patrick McHardy wrote:
Without having thought much about it yet, roughly like this:
- driver receives RTM_NEWLINK message (under rtnl)
- driver allocates new device
- driver initializes device based on content of RTM_NEWLINK message
- driver returns
Johannes Berg wrote:
On Tue, 2007-04-10 at 11:52 +0200, Patrick McHardy wrote:
Without having thought much about it yet, roughly like this:
- driver receives RTM_NEWLINK message (under rtnl)
- driver allocates new device
- driver initializes device based on content of RTM_NEWLINK message
-
On Tue, 2007-04-10 at 12:46 +0200, Patrick McHardy wrote:
Not totally different, so far I think we should use the same attributes
as for RTM_SETLINK messages and include the device-specific stuff in
IFLA_PROTINFO, which is symetric to what the kernel sends in RTM_NETLINK
messages (see
Waskiewicz Jr, Peter P [EMAIL PROTECTED] wrote:
@@ -3356,6 +3370,7 @@ void free_netdev(struct net_device *dev)
/* will free via device release */
put_device(dev-dev);
#else
+kfree((char *)dev-egress_subqueue);
kfree((char *)dev - dev-padded);
#endif
}
Ahem.
Johannes Berg wrote:
On Tue, 2007-04-10 at 12:46 +0200, Patrick McHardy wrote:
The main advantage that we don't get more weird sysfs/proc/ioctl based
interfaces
Please don't put me into a corner I don't want to be in ;) The new
wireless stuff was completely designed using netlink. The
Patrick McHardy wrote:
Maybe not wireless, but bonding, briding, vlan, etun, possibly more.
[if I understand you correctly] I agree. With ethtool, the idea is to
have a single tool that supports multiple hardware platforms -- even to
the point of introducing hardware-specific code into
Evgeniy Polyakov wrote:
But it looks from this discussion, that it will not prevent from
changing in-kernel driver - place a hook into skb allocation path and
allocate data from opposing memory - get pages from another side and put
them into fragments, then copy headers into skb-data.
On Tue, 2007-04-10 at 13:09 +0200, Patrick McHardy wrote:
I know :) It was a few month ago when I noticed the new bonding
sysfs interface when I first thought that we really need this.
:)
I don't think wireless can get away without a new tool. So much stuff
there. Look at
On Tue, Apr 10, 2007 at 02:21:24PM +0300, Avi Kivity ([EMAIL PROTECTED]) wrote:
You want to implement zero-copy network device between host and guest, if
I understood this thread correctly?
So, for sending part, device allocates pages from receiver's memory (or
from shared memory), receiver
Johannes Berg wrote:
Fair enough. Then the question however remains whether wireless should
try to do all things it needs in one or try leveraging multiple things
from other places. Thoughts?
I know too little about wireless to judge really this. My opinion is
that if it is possible to add
Evgeniy Polyakov wrote:
This is what Xen does. It is actually less performant than copying, IIRC.
The problem with flipping pages around is that physical addresses are
cached both in the kvm mmu and in the on-chip tlbs, necessitating
expensive page table walks and tlb invalidation IPIs.
On Tue, Apr 10, 2007 at 03:17:45PM +0300, Avi Kivity ([EMAIL PROTECTED]) wrote:
Check a link please in case we are talking about different ideas:
http://marc.info/?l=linux-netdevm=112262743505711w=2
I don't really understand what you're testing there. in particular, how
can the
Evgeniy Polyakov wrote:
On Tue, Apr 10, 2007 at 03:17:45PM +0300, Avi Kivity ([EMAIL PROTECTED]) wrote:
Check a link please in case we are talking about different ideas:
http://marc.info/?l=linux-netdevm=112262743505711w=2
I don't really understand what you're testing there. in
Robin Getz [EMAIL PROTECTED] wrote:
David - I know you have been reworking the noMMU vma handling - is there a
solution to vm_insert_page?
The reason vm_insert_page() is being called, I imagine, is because
packet_mmap() has to insert mappings to an already existing buffer. All it
does is
On Tue, 2007-04-10 at 14:05 +0200, Patrick McHardy wrote:
I know too little about wireless to judge really this. My opinion is
that if it is possible to add and configure an interface (even if
only for simple cases) without knowledge about driver internals by
setting a few parameters, it
W Agtail wrote:
On Mon, 2007-04-09 at 11:11 -0700, Ben Greear wrote:
W Agtail wrote:
Nice one, but unfortunately still doesn't work.
I'm now not seeing any marked messages in /var/log/messages and traffic
still going via gw2 for port 8088.
Maybe you could use something like my
On Mon, Apr 09, 2007 at 02:28:41PM -0700, Peter P Waskiewicz
Jr ([EMAIL PROTECTED]) wrote:
+ alloc_size = (sizeof(struct net_device_subqueue) * queue_count);
+
+ p = kzalloc(alloc_size, GFP_KERNEL);
+ if (!p) {
+ printk(KERN_ERR alloc_netdev: Unable to
allocate
On Tue, Apr 10, 2007 at 08:41:49AM -0700, Waskiewicz Jr, Peter P ([EMAIL
PROTECTED]) wrote:
On Mon, Apr 09, 2007 at 02:28:41PM -0700, Peter P Waskiewicz
Jr ([EMAIL PROTECTED]) wrote:
+ alloc_size = (sizeof(struct net_device_subqueue) * queue_count);
+
+ p =
Peter P Waskiewicz Jr wrote:
+ /* To retrieve statistics per subqueue - FOR FUTURE USE */
+ struct net_device_stats* (*get_subqueue_stats)(struct
net_device *dev,
+ int
queue_index);
Please no future use stuff, just add it when
On Thu, Apr 05, Valerie Henson wrote:
On Tue, Apr 03, 2007 at 11:19:16PM +0200, Olaf Hering wrote:
From: [EMAIL PROTECTED]
https://bugzilla.novell.com/show_bug.cgi?id=SUSE39204
Wow, registering for Novell's bugzilla is painful. And in the end I
get Access denied on that bug. Can
Hi David
Please find this patch against net-2.6.22
Thank you
[PATCH] NET : loopback driver can use loopback_dev integrated net_device_stats
Rusty added a new 'stats' field to struct net_device.
loopback driver can use it instead of declaring another struct net_device_stats
This saves some
I've got an DVB-C-box called Dreambox DM500-C and it uses the
AX88796-chip for networking. They (Dream Multimedia, makers of the
Dreambox) has patched the NE2000-drivers in the kernel (ne.c), but only to
get it working. As a result it doesn't seem to be performing more than
20-30 Mbps.
I found
Hi Guennadi,
On Sat, Apr 07, 2007 at 03:59:26AM +0300, Samuel Ortiz wrote:
IMHO, irnet_flow_indication() should be called asynchronously by
irttp_run_tx_queue(), through some bottom-half mechanism. That would fix your
locking issues, and that would reduce the time we spend in the IrDA code
Hi Jeff,
In case it is not too late for 2.6.21, here are 3 minor fixes for myri10ge:
1. fix management of the firmware 4KB boundary crossing restriction
2. more Intel chipsets providing aligned PCIe completions
3. update driver version to 1.3.0-1.233
Thanks,
Brice
-
To unsubscribe from this
Simpler way of dealing with the firmware 4KB boundary crossing
restriction for rx buffers. This fixes a variety of memory
corruption issues when using an uncommon MTU with a 16KB
page size.
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
---
drivers/net/myri10ge/myri10ge.c | 19
Add the Intel 5000 southbridge (aka Intel 6310/6311/6321ESB) PCIe ports
and the Intel E30x0 chipsets to the whitelist of aligned PCIe completion.
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
---
drivers/net/myri10ge/myri10ge.c | 17 +
1 file changed, 17 insertions(+)
Index:
Update the myri10ge driver version number to 1.3.0-1.233.
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
---
drivers/net/myri10ge/myri10ge.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-rc/drivers/net/myri10ge/myri10ge.c
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Mon, 9 Apr 2007 13:55:52 -0700
Here is an update to bridging code for net-2.6.22
The following changes since commit 532122caf3f7573760c5ec523bc3be14606bb8f2:
Ilpo Järvinen (1):
[TCP]: Simplify LOST marker code
are found in the git
I've been keeping an eye on PHYLIB since it's addition to the kernel
some time ago and I'm a bit curious as to why it doesn't seem to have
much up-take among other drivers. A quick check of the kernel source
shows only two users (AU1000 and gianfar) and both look to be embedded
type devices. Are
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 10 Apr 2007 19:29:12 +0200
Hi David
Please find this patch against net-2.6.22
Thank you
[PATCH] NET : loopback driver can use loopback_dev integrated net_device_stats
Rusty added a new 'stats' field to struct net_device.
loopback
As the merge window approaches I've made a decision about how to
handle the TCP RB-Tree work since it's getting really close.
First, I'm going to rebase the net-2.6.22 tree after making a quick
run through my patch backlog looking for low hanging fruit. I will
include the TCP write queue
Hi Dave
Please consider applying the following two patches. They resolve some
interesting bugs.
Thanks
-vlad
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Sorry, now with the patches that follow...
-vlad
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Paolo Galtieri [EMAIL PROTECTED]
During the sctp_bindx() call to add additional addresses to the
endpoint, any v4mapped addresses are converted and stored as regular
v4 addresses. However, when trying to remove these addresses, the
v4mapped addresses are not converted and the operation
From: Tsutomu Fujii [EMAIL PROTECTED]
In current implementation, LKSCTP does receive buffer accounting for
data in sctp_receive_queue and pd_lobby. However, LKSCTP don't do
accounting for data in frag_list when data is fragmented. In addition,
LKSCTP doesn't do accounting for data in reasm and
Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
Index: linux-2.6.21-rc5/net/ipv4/ipvs/Kconfig
===
---
(Wow, not a single MODULE_AUTHOR line in drivers/net/arcnet/ ...)
Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
Index: linux-2.6.21-rc5/drivers/net/arcnet/Kconfig
(No MAINTAINERS entry. MODULE_AUTHOR lines exist, but without addresses.)
Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
Index: linux-2.6.21-rc5/drivers/net/phy/Kconfig
Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
Index: linux-2.6.21-rc5/drivers/net/tokenring/Kconfig
===
---
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
please consider for 2.6.22
drivers/net/ucc_geth.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 1b943e6..c9b1b28 100644
--- a/drivers/net/ucc_geth.c
+++
From: Michael Barkowski [EMAIL PROTECTED]
The ICPlus IP175C sports a 100Mbit/s 5-port switch in addition
to a dedicated 100Mbit/s WAN port.
Signed-off-by: Michael Barkowski [EMAIL PROTECTED]
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
please consider for 2.6.22
drivers/net/phy/Kconfig |
Distinguish between the Davicom DM9161A PHY and the DM9161E.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
please consider for 2.6.22
drivers/net/phy/davicom.c | 34 ++
1 files changed, 26 insertions(+), 8 deletions(-)
diff --git
also adds RX TX delay bits to help boards with clock skew problems.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
please consider for 2.6.22
drivers/net/phy/marvell.c | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git
Thomas Langås [EMAIL PROTECTED] :
[...]
I found a driver [1] that I managed to patch into the linux 2.6.9-kernel,
but upon booting the dreambox it doesn't detect the networkcard. I suspect
it because of this (found inside the ne.c-file used by the dreambox):
From a (very) quick sight at [1]
On Tue, 10 Apr 2007 14:41:01 -0400
David Hollis [EMAIL PROTECTED] wrote:
I've been keeping an eye on PHYLIB since it's addition to the kernel
some time ago and I'm a bit curious as to why it doesn't seem to have
much up-take among other drivers. A quick check of the kernel source
shows only
On Tue 10 Apr 2007 08:55, David Howells pondered:
Looking at alloc_pg_vec() in af_packet.c, I will place my bets on the
latter case. I don't know that this is a problem; it depends on how things
work, and that I don't know offhand. If someone can give me a simple test
program, I would be
Hi Dave,
Patrick McHardy wrote:
[SK_BUFF]: Fix missing offset adjustment in skb_copy_expand
skb_copy_expand changes the headroom, so it needs to adjust the header
offsets by the difference between the old and the new value.
it seems like you missed this one. Attached again for your
On Tue, Apr 10, 2007 at 05:20:52PM -0500, Kim Phillips wrote:
(note I'm coming from an embedded world here.)
Please read this:
http://marc.info/?l=linux-netdevm=116527863300952w=2
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
On Tue, 10 Apr 2007 20:56:16 -0400
Mathieu Desnoyers [EMAIL PROTECTED] wrote:
The last for today : link error of 2.6.21-rc6-mm1 for s390 :
/opt/crosstool/gcc-4.1.1-glibc-2.3.6/s390-unknown-linux-gnu/bin/s390-unknown-linux-gnu-ld
-m elf_s390 -e start -o .tmp_vmlinux1 -T
From: Patrick McHardy [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 02:42:59 +0200
Hi Dave,
Patrick McHardy wrote:
[SK_BUFF]: Fix missing offset adjustment in skb_copy_expand
skb_copy_expand changes the headroom, so it needs to adjust the header
offsets by the difference between the old
From: Andrew Morton [EMAIL PROTECTED]
Date: Tue, 10 Apr 2007 18:29:37 -0700
git-net.patch implements generic lib/div64.c, but s390 also has a
private one. Presumably the appropriate fix is to remove s390's
private implementation within davem's tree.
The s390 version seems to be optimized in
On Tue, 10 Apr 2007 18:36:29 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Andrew Morton [EMAIL PROTECTED]
Date: Tue, 10 Apr 2007 18:29:37 -0700
git-net.patch implements generic lib/div64.c, but s390 also has a
private one. Presumably the appropriate fix is to remove s390's
From: Andrew Morton [EMAIL PROTECTED]
Date: Tue, 10 Apr 2007 18:47:38 -0700
On Tue, 10 Apr 2007 18:36:29 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Andrew Morton [EMAIL PROTECTED]
Date: Tue, 10 Apr 2007 18:29:37 -0700
git-net.patch implements generic lib/div64.c, but
On Mon, 2007-04-09 at 16:38 +0300, Avi Kivity wrote:
Moreover, some things just don't lend themselves to a userspace
abstraction. If we want to expose tso (tcp segmentation offload), we
can easily do so with a kernel driver since the kernel interfaces are
all tso aware. Tacking on tso
Rusty Russell wrote:
On Mon, 2007-04-09 at 16:38 +0300, Avi Kivity wrote:
Moreover, some things just don't lend themselves to a userspace
abstraction. If we want to expose tso (tcp segmentation offload), we
can easily do so with a kernel driver since the kernel interfaces are
all tso
Hi,
For some per-flow queue management work I need to access TCP port
numbers of an skb inside a qdisc (i.e. in qdisc enqueue and dequeue
functions). Can I assume that skb-data always points to the head of
the IP header of the packet? If that is the case will the following
statements do the
On Tue, Apr 10, 2007 at 11:25:59PM +0200, Jan Engelhardt wrote:
Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
This seems to work fine to me.
Signed-off-by: Simon
From: Andrew Morton [EMAIL PROTECTED]
Date: Tue, 10 Apr 2007 18:47:38 -0700
attribute(weak) would give a nicer result?
We'd also need to remove s390's EXPORT_SYMBOL(__div64_32), so s390 ends up
using lib/div64.c's EXPORT_SYMBOL().
Ok, here is the version of the fix I'll use for now:
commit
Stephen Hemminger wrote:
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index a260679..8a55276 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
if (unlikely(is_link_local(dest))) {
skb-pkt_type = PACKET_HOST;
- return
Waskiewicz Jr, Peter P wrote:
This leaks the device. You treat every single-queue device as
having a single subqueue. If it doesn't get too ugly it would
be nice to avoid this and only allocate the subqueue states
for real multiqueue devices.
We went back and forth on this. The reason we
72 matches
Mail list logo
