* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov @ 2006-04-28 16:12 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: David S. Miller, kelly, rusty, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F143B0E2@NT-SJCA-0751.brcm.ad.broadcom.com>
On Fri, Apr 28, 2006 at 08:59:19AM -0700, Caitlin Bestler (caitlinb@broadcom.com) wrote:
> > Btw, how is it supposed to work without header split capabale
> > hardware?
>
> Hardware that can classify packets is obviously capable of doing
> header data separation, but that does not mean that it has to do so.
>
> If the host wants header data separation it's real value is that when
> packets arrive in order that fewer distinct copies are required to
> move the data to the user buffer (because separated data can
> be placed back-to-back in a data-only ring). But that's an optimization,
> it's not needed to make the idea worth doing, or even necessarily
> in the first implementation.
If there is dataflow, not flow of packets or flow of data with holes,
it could be possible to modify recv() to just return the right pointer,
so in theory userspace modifications would be minimal.
With copy in place it completely does not differ from current design
with copy_to_user() being used since memcpy() is just slightly faster
than copy*user().
--
Evgeniy Polyakov
^ permalink raw reply
* RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Caitlin Bestler @ 2006-04-28 17:02 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: David S. Miller, kelly, rusty, netdev
Evgeniy Polyakov wrote:
> On Fri, Apr 28, 2006 at 08:59:19AM -0700, Caitlin Bestler
> (caitlinb@broadcom.com) wrote:
>>> Btw, how is it supposed to work without header split capabale
>>> hardware?
>>
>> Hardware that can classify packets is obviously capable of doing
>> header data separation, but that does not mean that it has to do so.
>>
>> If the host wants header data separation it's real value is that when
>> packets arrive in order that fewer distinct copies are required to
>> move the data to the user buffer (because separated data can be
>> placed back-to-back in a data-only ring). But that's an
>> optimization, it's not needed to make the idea worth doing, or even
>> necessarily in the first implementation.
>
> If there is dataflow, not flow of packets or flow of data
> with holes, it could be possible to modify recv() to just
> return the right pointer, so in theory userspace
> modifications would be minimal.
> With copy in place it completely does not differ from current
> design with copy_to_user() being used since memcpy() is just
> slightly faster than copy*user().
If the app is really ready to use a modified interface we might as well
just give them a QP/CQ interface. But I suppose "receive by pointer"
interfaces don't really stretch the sockets interface all that badly.
The key is that you have to decide how the buffer is released,
is it the next call? Or a separate call? Does releasing buffer
N+2 release buffers N and N+1? What you want to avoid
is having to keep a scoreboard of which buffers have been
released.
But in context, header/data separation would allow in order
packets to have the data be placed back to back, which
could allow a single recv to report the payload of multiple
successive TCP segments. So the benefit of header/data
separation remains the same, and I still say it's a optimization
that should not be made a requirement. The benefits of vj_channels
exist even without them. When the packet classifier runs on the
host, header/data separation would not be free. I want to enable
hardware offloads, not make the kernel bend over backwards
to emulate how hardware would work. I'm just hoping that we
can agree to let hardware do its work without being forced to
work the same way the kernel does (i.e., running down a long
list of arbitrary packet filter rules on a per packet basis).
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Stephen Hemminger @ 2006-04-28 17:18 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: Evgeniy Polyakov, David S. Miller, kelly, rusty, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F143B0F3@NT-SJCA-0751.brcm.ad.broadcom.com>
On Fri, 28 Apr 2006 10:02:10 -0700
"Caitlin Bestler" <caitlinb@broadcom.com> wrote:
> Evgeniy Polyakov wrote:
> > On Fri, Apr 28, 2006 at 08:59:19AM -0700, Caitlin Bestler
> > (caitlinb@broadcom.com) wrote:
> >>> Btw, how is it supposed to work without header split capabale
> >>> hardware?
> >>
> >> Hardware that can classify packets is obviously capable of doing
> >> header data separation, but that does not mean that it has to do so.
> >>
> >> If the host wants header data separation it's real value is that when
> >> packets arrive in order that fewer distinct copies are required to
> >> move the data to the user buffer (because separated data can be
> >> placed back-to-back in a data-only ring). But that's an
> >> optimization, it's not needed to make the idea worth doing, or even
> >> necessarily in the first implementation.
> >
> > If there is dataflow, not flow of packets or flow of data
> > with holes, it could be possible to modify recv() to just
> > return the right pointer, so in theory userspace
> > modifications would be minimal.
> > With copy in place it completely does not differ from current
> > design with copy_to_user() being used since memcpy() is just
> > slightly faster than copy*user().
>
> If the app is really ready to use a modified interface we might as well
> just give them a QP/CQ interface. But I suppose "receive by pointer"
> interfaces don't really stretch the sockets interface all that badly.
> The key is that you have to decide how the buffer is released,
> is it the next call? Or a separate call? Does releasing buffer
> N+2 release buffers N and N+1? What you want to avoid
> is having to keep a scoreboard of which buffers have been
> released.
>
Please just use existing AIO interface. We don't need another
interface. The number of interfaces increases the exposed bug
surface geometrically. Which means for each new interface, it
means testing and fixing bugs in every possible usage.
> But in context, header/data separation would allow in order
> packets to have the data be placed back to back, which
> could allow a single recv to report the payload of multiple
> successive TCP segments. So the benefit of header/data
> separation remains the same, and I still say it's a optimization
> that should not be made a requirement. The benefits of vj_channels
> exist even without them. When the packet classifier runs on the
> host, header/data separation would not be free. I want to enable
> hardware offloads, not make the kernel bend over backwards
> to emulate how hardware would work. I'm just hoping that we
> can agree to let hardware do its work without being forced to
> work the same way the kernel does (i.e., running down a long
> list of arbitrary packet filter rules on a per packet basis).
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] netem: fix loss
From: Stephen Hemminger @ 2006-04-28 17:22 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, George Nychis, netem
The following one line fix is needed to make loss function of
netem work right when doing loss on the local host.
Otherwise, higher layers just recover.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
--- linux-2.6.orig/net/sched/sch_netem.c
+++ linux-2.6/net/sched/sch_netem.c
@@ -167,7 +167,7 @@ static int netem_enqueue(struct sk_buff
if (count == 0) {
sch->qstats.drops++;
kfree_skb(skb);
- return NET_XMIT_DROP;
+ return NET_XMIT_BYPASS;
}
/*
^ permalink raw reply
* Re: [LARTC] how to change classful netem loss probability?
From: Stephen Hemminger @ 2006-04-28 17:24 UTC (permalink / raw)
To: George P Nychis; +Cc: George Nychis, lartc, netdev
In-Reply-To: <32923.128.2.140.234.1146187103.squirrel@128.2.140.234>
Loss was broken, patch sent.
The following works now:
# tc qdisc add dev eth1 root handle 1:0 netem loss 20%
# tc qdisc add dev eth1 parent 1:1 handle 10: tbf \
rate 256kbit buffer 1600 limit 3000
# ping -f -c 1000 shell
1000 packets transmitted, 781 received, 21% packet loss, time 3214ms
rtt min/avg/max/mdev = 0.187/0.398/3.763/0.730 ms, ipg/ewma 3.217/0.538 ms
# tc qdisc chang dev eth1 handle 1: netem loss 1%
# ping -f -c 1000 shell
1000 packets transmitted, 990 received, 1% packet loss, time 2922ms
rtt min/avg/max/mdev = 0.187/2.739/3.298/0.789 ms, ipg/ewma 2.924/2.084 ms
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov @ 2006-04-28 17:25 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: David S. Miller, kelly, rusty, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F143B0F3@NT-SJCA-0751.brcm.ad.broadcom.com>
On Fri, Apr 28, 2006 at 10:02:10AM -0700, Caitlin Bestler (caitlinb@broadcom.com) wrote:
> If the app is really ready to use a modified interface we might as well
> just give them a QP/CQ interface. But I suppose "receive by pointer"
> interfaces don't really stretch the sockets interface all that badly.
> The key is that you have to decide how the buffer is released,
> is it the next call? Or a separate call? Does releasing buffer
> N+2 release buffers N and N+1? What you want to avoid
> is having to keep a scoreboard of which buffers have been
> released.
>
> But in context, header/data separation would allow in order
> packets to have the data be placed back to back, which
> could allow a single recv to report the payload of multiple
> successive TCP segments. So the benefit of header/data
> separation remains the same, and I still say it's a optimization
> that should not be made a requirement. The benefits of vj_channels
> exist even without them. When the packet classifier runs on the
> host, header/data separation would not be free. I want to enable
> hardware offloads, not make the kernel bend over backwards
> to emulate how hardware would work. I'm just hoping that we
> can agree to let hardware do its work without being forced to
> work the same way the kernel does (i.e., running down a long
> list of arbitrary packet filter rules on a per packet basis).
I see your point, and respectfully disagree.
The more complex userspace interface we create the less users it will
have. It is completely unconvenient to read 100 bytes and receive only
80, since 20 were eaten by header. And what if we need only 20, but
packet contains 100, introduce per packet head pointer?
For purpose of benchmarking it works perfectly -
read the whole packet, one can event touch that data to emulate real
work, but for the real world it becomes practically unusabl.
But what we are talking about right now is a research project, not
production system, so we can create any interface we like since the main
goal, IMHO, is searching for the bottlenecks in the current stack and
ways of it's removal even by introducing new complex interface.
I would definitely like to see how your approach works for some
kind of real workloads and does it allow to
create faster and generally better systems.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov @ 2006-04-28 17:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Caitlin Bestler, David S. Miller, kelly, rusty, netdev
In-Reply-To: <20060428101833.2f0d6ae8@localhost.localdomain>
On Fri, Apr 28, 2006 at 10:18:33AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> Please just use existing AIO interface. We don't need another
> interface. The number of interfaces increases the exposed bug
> surface geometrically. Which means for each new interface, it
> means testing and fixing bugs in every possible usage.
Networking AIO? Like [1] :)
That would be really good.
1. http://tservice.net.ru/~s0mbre/old/?section=projects&item=naio
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Stephen Hemminger @ 2006-04-28 17:41 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: Caitlin Bestler, David S. Miller, kelly, rusty, netdev
In-Reply-To: <20060428172932.GB16916@2ka.mipt.ru>
On Fri, 28 Apr 2006 21:29:32 +0400
Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> On Fri, Apr 28, 2006 at 10:18:33AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> > Please just use existing AIO interface. We don't need another
> > interface. The number of interfaces increases the exposed bug
> > surface geometrically. Which means for each new interface, it
> > means testing and fixing bugs in every possible usage.
>
> Networking AIO? Like [1] :)
> That would be really good.
>
> 1. http://tservice.net.ru/~s0mbre/old/?section=projects&item=naio
>
The existing infrastructure is there in the syscall layer, it just
isn't really AIO for sockets. That naio project has two problems, first
they require driver changes, and he is doing it on the stupidest
of hardware, optimizing a 8139too is foolish. Second, introducing
kevents, seems unnecessary and hasn't been accepted in the mainline.
The existing linux AIO model seems sufficient:
http://lse.sourceforge.net/io/aio.html
There is work to put true Posix AIO on top of this.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov @ 2006-04-28 17:55 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Caitlin Bestler, David S. Miller, kelly, rusty, netdev
In-Reply-To: <20060428104118.6a056a59@localhost.localdomain>
On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> On Fri, 28 Apr 2006 21:29:32 +0400
> Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
>
> > On Fri, Apr 28, 2006 at 10:18:33AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> > > Please just use existing AIO interface. We don't need another
> > > interface. The number of interfaces increases the exposed bug
> > > surface geometrically. Which means for each new interface, it
> > > means testing and fixing bugs in every possible usage.
> >
> > Networking AIO? Like [1] :)
> > That would be really good.
> >
> > 1. http://tservice.net.ru/~s0mbre/old/?section=projects&item=naio
> >
>
> The existing infrastructure is there in the syscall layer, it just
> isn't really AIO for sockets. That naio project has two problems, first
> they require driver changes, and he is doing it on the stupidest
> of hardware, optimizing a 8139too is foolish.
No, it does not. You confuse it with receiving zero-copy support which
allows to DMA data directly into VFS cache [1].
NAIO works for any kind of hardware and was tested with e1000 and showed
noticeble win in both CPU usage and network performance.
> Second, introducing
> kevents, seems unnecessary and hasn't been accepted in the mainline.
kevent was never sent to lkml@ although it showed over 40% win over epoll for
test web server. Sending it to lkml@ is just jumping into ... not into
technical world, so I posted it first here, but without much attention
though.
> The existing linux AIO model seems sufficient:
> http://lse.sourceforge.net/io/aio.html
>
> There is work to put true Posix AIO on top of this.
There are a lot of discussions about combining AIO with epoll and
combine them into something similar to kevent which allows to monitor
level and edge triggered events, to create proper state machine for AIO
compeltions. kevent [2] does exactly that. AIO works not as state
machine, but it's repeated-check design is more like postponing work
from one context to special thread.
1. receiving zero-copy support
http://tservice.net.ru/~s0mbre/old/?section=projects&item=recv_zero_copy
2. kevent system
http://tservice.net.ru/~s0mbre/old/?section=projects&item=kevent
--
Evgeniy Polyakov
^ permalink raw reply
* RE: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Caitlin Bestler @ 2006-04-28 17:55 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: David S. Miller, kelly, rusty, netdev
Evgeniy Polyakov wrote:
>
> I see your point, and respectfully disagree.
> The more complex userspace interface we create the less users
> it will have. It is completely unconvenient to read 100 bytes
> and receive only 80, since 20 were eaten by header. And what
> if we need only 20, but packet contains 100, introduce per packet
> head pointer? For purpose of benchmarking it works perfectly - read
> the whole packet, one can event touch that data to emulate real
> work, but for the real world it becomes practically unusabl.
>
In a straight-forward user-mode library using existing interfaces the
message would be interleaved with the headers in the inbound ring.
While the inbound ring is part of user memory, it is not what the
user would process from, that would be the buffer they supplied
in a call to read() or recvmsg(), that buffer would have to make
no allowances for interleaved headers.
Enabling zero-copy when a buffer is pre-posted is possible, but
modestly complex. Research on MPI and SDP have generally
shown that the unless the pinning overhead is eliminated somehow
that the buffers have to be quite large before zero-copy reception
becomes a benefit. vj_netchannels represent a strategy of minimizing
registration/pinning costs even if it means paying for an extra copy.
Because the extra copy is closely tied to the activation of the data
sink consumer the cost of that extra copy is greatly reduced because
it places the data in the cache immediately before the application
will in fact use the received data.
Also keep in mind that once the issues are resolved to allow the
netchannel rings to be directly visible to a user-mode client that
enhanced/specialized interfaces can easily be added in user-mode
libraries. So focusing on supporting existing conventional interfaces
is probably the best approach for the initial efforts.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 18:20 UTC (permalink / raw)
To: johnpol; +Cc: caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428073216.GB3378@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Fri, 28 Apr 2006 11:32:16 +0400
> Definitely, userspace application must be very smart to deal with
> ip/tcp/option headers...
That is why we will put an "offset+len" in the ring so they need not
parse the packet headers.
^ permalink raw reply
* [PATCH] rt2x00: Compile fix and kernel version cleanup
From: Ivo van Doorn @ 2006-04-28 18:52 UTC (permalink / raw)
To: netdev; +Cc: rt2x00-devel
[-- Attachment #1: Type: text/plain, Size: 5789 bytes --]
From: Ivo van Doorn <IvDoorn@gmail.com>
During CVS merge I noticed several compilation errors have sneaked
into the git version of rt2x00.
- PRIO_ENTRIES define has been removed, TX_ENTRIES should be used
- poll_delay module argument is of the type short
- Remove LINUX_VERSION_CODE checks.
- Fix missing byteordering type
- Fix typo in usb_device
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-04-28 20:49:32.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2400pci.c 2006-04-28 20:50:40.000000000 +0200
@@ -1239,7 +1239,7 @@ rt2400pci_allocate_rings(struct rt2x00_p
ATIM_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2400pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_PRIO], rt2400pci_txdone,
- PRIO_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
+ TX_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2400pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_BEACON], rt2400pci_beacondone,
BEACON_ENTRIES, MGMT_FRAME_SIZE, sizeof(struct txd))) {
@@ -2729,14 +2729,12 @@ MODULE_PARM_DESC(debug, "Set this parame
#endif /* CONFIG_RT2400PCI_DEBUG */
#ifdef CONFIG_RT2400PCI_BUTTON
-module_param_named(poll_delay, rt2x00_poll_delay, int, S_IRUGO);
+module_param_named(poll_delay, rt2x00_poll_delay, short, S_IRUGO);
MODULE_PARM_DESC(debug, "Delay between WiFi button pollings (in 100ms).");
#endif /* CONFIG_RT2400PCI_BUTTON */
static struct pci_driver rt2400pci_driver = {
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14)
.owner = THIS_MODULE,
-#endif /* LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14) */
.name = DRV_NAME,
.id_table = rt2400pci_device_table,
.probe = rt2400pci_probe,
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-04-28 20:49:45.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.c 2006-04-28 20:50:39.000000000 +0200
@@ -1328,7 +1328,7 @@ rt2500pci_allocate_rings(struct rt2x00_p
ATIM_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2500pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_PRIO], rt2500pci_txdone,
- PRIO_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
+ TX_ENTRIES, DATA_FRAME_SIZE, sizeof(struct txd))
|| rt2500pci_alloc_ring(
rt2x00pci, &rt2x00pci->ring[RING_BEACON], rt2500pci_beacondone,
BEACON_ENTRIES, MGMT_FRAME_SIZE, sizeof(struct txd))) {
@@ -3032,14 +3032,12 @@ MODULE_PARM_DESC(debug, "Set this parame
#endif /* CONFIG_RT2500PCI_DEBUG */
#ifdef CONFIG_RT2500PCI_BUTTON
-module_param_named(poll_delay, rt2x00_poll_delay, int, S_IRUGO);
+module_param_named(poll_delay, rt2x00_poll_delay, short, S_IRUGO);
MODULE_PARM_DESC(debug, "Delay between WiFi button pollings (in 100ms).");
#endif /* CONFIG_RT2500PCI_BUTTON */
static struct pci_driver rt2500pci_driver = {
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14)
.owner = THIS_MODULE,
-#endif /* LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 14) */
.name = DRV_NAME,
.id_table = rt2500pci_device_table,
.probe = rt2500pci_probe,
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.h wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500pci.h 2006-04-28 15:58:29.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500pci.h 2006-04-28 20:28:58.000000000 +0200
@@ -1005,7 +1005,7 @@ struct txd{
__le32 word1;
#define TXD_W1_BUFFER_ADDRESS FIELD32(0xffffffff)
- u32 word2;
+ __le32 word2;
#define TXD_W2_IV_OFFSET FIELD32(0x0000003f)
#define TXD_W2_AIFS FIELD32(0x000000c0)
#define TXD_W2_CWMIN FIELD32(0x00000f00)
diff -uprN wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
--- wireless-dev-rt2x00/drivers/net/wireless/d80211/rt2x00/rt2500usb.c 2006-04-28 20:49:59.000000000 +0200
+++ wireless-dev-rt2x00-cvs/drivers/net/wireless/d80211/rt2x00/rt2500usb.c 2006-04-28 20:50:39.000000000 +0200
@@ -1362,7 +1362,7 @@ rt2500usb_tx(struct net_device *net_dev,
struct sk_buff *skb, struct ieee80211_tx_control *control)
{
struct rt2x00_usb *rt2x00usb = ieee80211_dev_hw_data(net_dev);
- struct usb_devive *usb_dev =
+ struct usb_device *usb_dev =
interface_to_usbdev(rt2x00usb->usb_intf);
struct data_ring *ring;
struct data_entry *entry;
@@ -1844,7 +1844,7 @@ rt2500usb_beacon_update(struct net_devic
struct sk_buff *skb, struct ieee80211_tx_control *control)
{
struct rt2x00_usb *rt2x00usb = ieee80211_dev_hw_data(net_dev);
- struct usb_devive *usb_dev =
+ struct usb_device *usb_dev =
interface_to_usbdev(rt2x00usb->usb_intf);
struct data_entry *entry;
@@ -2074,7 +2074,7 @@ rt2500usb_init_hw_channels(struct rt2x00
channels[counter].val = vals[counter];
}
- /*
+ /*
* Set TX power, each EEPROM TXpower entry
* contains the TXpower value for 2 channels.
*/
@@ -2628,9 +2628,7 @@ MODULE_PARM_DESC(debug, "Set this parame
#endif /* CONFIG_RT2500USB_DEBUG */
static struct usb_driver rt2500usb_driver = {
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 15)
.owner = THIS_MODULE,
-#endif /* LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 15) */
.name = DRV_NAME,
.id_table = rt2500usb_device_table,
.probe = rt2500usb_probe,
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1]x25: fix for spinlock recurse and spinlock lockup with timer handler in x25
From: David S. Miller @ 2006-04-28 19:00 UTC (permalink / raw)
To: spereira; +Cc: akpm, netdev, eis, linux-x25, linux-kernel
In-Reply-To: <1145509403.16180.10.camel@spereira05.tusc.com.au>
From: Shaun Pereira <spereira@tusc.com.au>
Date: Thu, 20 Apr 2006 15:03:23 +1000
> From: spereira@tusc.com.au
>
> When the sk_timer function x25_heartbeat_expiry() is called by the kernel
> in a running/terminating process, spinlock-recursion and spinlock-lockup
> locks up the kernel.
> This has happened with testing on some distro's and the patch below fixed it.
>
> Signed-off-by:Shaun Pereira <spereira@tusc.com.au>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 19:09 UTC (permalink / raw)
To: johnpol; +Cc: caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428161221.GA12357@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Fri, 28 Apr 2006 20:12:21 +0400
> If there is dataflow, not flow of packets or flow of data with holes,
> it could be possible to modify recv() to just return the right pointer,
> so in theory userspace modifications would be minimal.
> With copy in place it completely does not differ from current design
> with copy_to_user() being used since memcpy() is just slightly faster
> than copy*user().
I very much feel that avoiding userland API changes is
a complete mistake.
We need new interfaces to do this right.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 19:10 UTC (permalink / raw)
To: shemminger; +Cc: caitlinb, johnpol, kelly, rusty, netdev
In-Reply-To: <20060428101833.2f0d6ae8@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Fri, 28 Apr 2006 10:18:33 -0700
> Please just use existing AIO interface.
I totally disagree, the existing AIO interface is garbage.
We need new APIs to do this right, to get the ring buffer
and the zero-copy'ness correct.
^ permalink raw reply
* Re: [PATCH] netem: fix loss
From: David S. Miller @ 2006-04-28 19:12 UTC (permalink / raw)
To: shemminger; +Cc: netdev, gnychis, netem
In-Reply-To: <20060428102240.59ba2a7a@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Fri, 28 Apr 2006 10:22:40 -0700
> The following one line fix is needed to make loss function of
> netem work right when doing loss on the local host.
> Otherwise, higher layers just recover.
>
> Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 19:14 UTC (permalink / raw)
To: johnpol; +Cc: caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428172536.GA16916@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Fri, 28 Apr 2006 21:25:36 +0400
> The more complex userspace interface we create the less users it will
> have. It is completely unconvenient to read 100 bytes and receive only
> 80, since 20 were eaten by header.
These bytes are charged to socket anyways, and allowing the
headers to be there is the only clean way to finesse the whole
zero-copy problem.
User can manage his data any way he likes. He can decide to take
advantage of the zero-copy layout we've provided, or he can copy
to put things into a format he is more happy with at the cost
of the copy.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 19:16 UTC (permalink / raw)
To: johnpol; +Cc: shemminger, caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428175538.GA13898@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Fri, 28 Apr 2006 21:55:39 +0400
> On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> > Second, introducing
> > kevents, seems unnecessary and hasn't been accepted in the mainline.
>
> kevent was never sent to lkml@ although it showed over 40% win over epoll for
> test web server. Sending it to lkml@ is just jumping into ... not into
> technical world, so I posted it first here, but without much attention
> though.
Frankly I found kevents to be a very strong idea.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: David S. Miller @ 2006-04-28 19:21 UTC (permalink / raw)
To: rusty; +Cc: caitlinb, johnpol, kelly, netdev
In-Reply-To: <1146212660.8029.38.camel@localhost.localdomain>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Fri, 28 Apr 2006 18:24:08 +1000
> Note that the problem space AFAICT includes strange advanced routing
> setups, ingress qos and possibly others, not just netfilter. But
> perhaps the same solutions apply, so I'll concentrate on nf.
Yes, this hasn't been mentioned explicitly yet.
The big problem is that we don't want the classifier to become
overly complex.
One scheme I'm thinking about right now is an ordered lookup
that looks like:
1) Check for established sockets, they trump everything else.
2) Check for classifier rules, ie. netfilter and packet scheduler
stuff
3) Check for listening sockets
4) default channel
#2 is still an unsolved problem, we don't want this big complex
classifier to be required in the hardware implementations.
However, using just IP addresses and ports does not map well to
what netfilter and co. want.
> Ah, this is a different problem. Our idea was to have a syscall which
> would check & sanitize the buffers for output. To do this, you need the
> ability to chain buffers (a simple next entry in the header, for us).
>
> Sanitization would copy the header into a global buffer (ie. not one
> reachable by userspace), check the flowid, and chain on the rest of the
> user buffer. After it had sanitized the buffers, it would activate the
> NIC, which would only send out buffers which started with a kernel
> buffer.
>
> Of course, the first step (CAP_NET_RAW-only) wouldn't need this. And,
> if the "sanitize_and_send" syscall were PF_VJCHAN's write(), then the
> contents of the write() could actually be the header: userspace would
> never deal with chained buffers.
I am not sure any of this is anything more than overhead.
If we just pop the buffers directly into the user mmap()'d ring
buffer, headers and all, and give an offset+length pair so the
user knows where the data starts and how much data is there, it
should all just work out. Where to put the offset+length is
just a detail.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Stephen Hemminger @ 2006-04-28 19:49 UTC (permalink / raw)
To: David S. Miller; +Cc: johnpol, caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428.121636.54294183.davem@davemloft.net>
On Fri, 28 Apr 2006 12:16:36 -0700 (PDT)
"David S. Miller" <davem@davemloft.net> wrote:
> From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> Date: Fri, 28 Apr 2006 21:55:39 +0400
>
> > On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> > > Second, introducing
> > > kevents, seems unnecessary and hasn't been accepted in the mainline.
> >
> > kevent was never sent to lkml@ although it showed over 40% win over epoll for
> > test web server. Sending it to lkml@ is just jumping into ... not into
> > technical world, so I posted it first here, but without much attention
> > though.
>
> Frankly I found kevents to be a very strong idea.
But there is this huge semantic overload of kevent, poll, epoll, aio,
regular sendmsg/recv, posix aio, etc.
Perhaps a clean break with the socket interface is needed. Otherwise, there
are nasty complications with applications that mix old socket calls and new interface
on the same connection.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov @ 2006-04-28 19:52 UTC (permalink / raw)
To: David S. Miller; +Cc: shemminger, caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428.121636.54294183.davem@davemloft.net>
On Fri, Apr 28, 2006 at 12:16:36PM -0700, David S. Miller (davem@davemloft.net) wrote:
> From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> Date: Fri, 28 Apr 2006 21:55:39 +0400
>
> > On Fri, Apr 28, 2006 at 10:41:18AM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> > > Second, introducing
> > > kevents, seems unnecessary and hasn't been accepted in the mainline.
> >
> > kevent was never sent to lkml@ although it showed over 40% win over epoll for
> > test web server. Sending it to lkml@ is just jumping into ... not into
> > technical world, so I posted it first here, but without much attention
> > though.
>
> Frankly I found kevents to be a very strong idea.
Glad to hear this.
I probably should resend patches netdev@ and (mar my karma) send it to
lkml@...?
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec
From: Santiago Leon @ 2006-04-28 19:51 UTC (permalink / raw)
To: michael; +Cc: jgarzik, anton, linuxppc64-dev, netdev
In-Reply-To: <1146047837.10735.29.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 314 bytes --]
Michael Ellerman wrote:
>>Looks like this hit the floor. Any chance of getting it into to 2.6.17
>>Jeff? AFAICT it should still apply cleanly.
>
> /me knocks politely
Actually, it doesn't apply cleanly anymore. Here's a patch that does.
--
Santiago A. Leon
Power Linux Development
IBM Linux Technology Center
[-- Attachment #2: ibmveth_harden_init.patch --]
[-- Type: text/plain, Size: 2193 bytes --]
From: Michael Ellerman <michael@ellerman.id.au>
After a kexec the ibmveth driver will fail when trying to register with the Hypervisor because the previous kernel has not unregistered.
So if the registration fails, we unregister and then try again.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Acked-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Santiago Leon <santil@us.ibm.com>
ibmveth.c | 31 ++++++++++++++++++++++++++-----
1 file changed, 26 insertions(+), 5 deletions(-)
Index: kexec/drivers/net/ibmveth.c
===================================================================
--- a/drivers/net/ibmveth.c 2006-04-28 13:16:22.244724056 -0500
+++ b/drivers/net/ibmveth.c 2006-04-28 13:29:49.429736784 -0500
@@ -436,6 +436,31 @@ static void ibmveth_cleanup(struct ibmve
ibmveth_free_buffer_pool(adapter, &adapter->rx_buff_pool[i]);
}
+static int ibmveth_register_logical_lan(struct ibmveth_adapter *adapter,
+ union ibmveth_buf_desc rxq_desc, u64 mac_address)
+{
+ int rc, try_again = 1;
+
+ /* After a kexec the adapter will still be open, so our attempt to
+ * open it will fail. So if we get a failure we free the adapter and
+ * try again, but only once. */
+retry:
+ rc = h_register_logical_lan(adapter->vdev->unit_address,
+ adapter->buffer_list_dma, rxq_desc.desc,
+ adapter->filter_list_dma, mac_address);
+
+ if (rc != H_SUCCESS && try_again) {
+ do {
+ rc = h_free_logical_lan(adapter->vdev->unit_address);
+ } while (H_IS_LONG_BUSY(rc) || (rc == H_BUSY));
+
+ try_again = 0;
+ goto retry;
+ }
+
+ return rc;
+}
+
static int ibmveth_open(struct net_device *netdev)
{
struct ibmveth_adapter *adapter = netdev->priv;
@@ -505,11 +530,7 @@ static int ibmveth_open(struct net_devic
ibmveth_debug_printk("receive q @ 0x%p\n", adapter->rx_queue.queue_addr);
- lpar_rc = h_register_logical_lan(adapter->vdev->unit_address,
- adapter->buffer_list_dma,
- rxq_desc.desc,
- adapter->filter_list_dma,
- mac_address);
+ lpar_rc = ibmveth_register_logical_lan(adapter, rxq_desc, mac_address);
if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk("h_register_logical_lan failed with %ld\n", lpar_rc);
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Evgeniy Polyakov @ 2006-04-28 19:59 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, caitlinb, kelly, rusty, netdev
In-Reply-To: <20060428124915.686911c1@localhost.localdomain>
On Fri, Apr 28, 2006 at 12:49:15PM -0700, Stephen Hemminger (shemminger@osdl.org) wrote:
> But there is this huge semantic overload of kevent, poll, epoll, aio,
> regular sendmsg/recv, posix aio, etc.
>
> Perhaps a clean break with the socket interface is needed. Otherwise, there
> are nasty complications with applications that mix old socket calls and new interface
> on the same connection.
kevent can be used as poll without any changes to the socket code.
There are two types of network related kevents - socket events
(recv/send/accept) and network aio, which can be turned completely off
in config.
There are following events which are supported by kevent:
o usual poll/select notifications
o inode notifications (create/remove)
o timer notifications
o socket notifications (send/recv/accept)
o network aio system
o fs aio (project closed, aio_sendfile() is being developed instead)
Any of the above can be turned off by config option.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Brent Cook @ 2006-04-28 20:46 UTC (permalink / raw)
To: David S. Miller; +Cc: shemminger, caitlinb, johnpol, kelly, rusty, netdev
In-Reply-To: <20060428.121052.39249337.davem@davemloft.net>
On Friday 28 April 2006 14:10, David S. Miller wrote:
> From: Stephen Hemminger <shemminger@osdl.org>
> Date: Fri, 28 Apr 2006 10:18:33 -0700
>
> > Please just use existing AIO interface.
>
> I totally disagree, the existing AIO interface is garbage.
>
> We need new APIs to do this right, to get the ring buffer
> and the zero-copy'ness correct.
> -
Heh, like PF_RING? Just mmap a socket and read out some structures?
^ permalink raw reply
* [patch] cleanup unused macro in net/netlink/af_netlink.c
From: S P @ 2006-04-28 20:51 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 232 bytes --]
1 line removal, of unused macro.
ran 'egrep -r' from linux-2.6.16/ for Nprintk and
didn't see it anywhere else but here, in #define...
------------------------------------------------
signed off by: soyoung park<speattle@yahoo.com>
[-- Attachment #2: 1497678878-remove_unused_macro.txt --]
[-- Type: text/plain, Size: 313 bytes --]
--- linux-2.6.16/net/netlink/af_netlink.c~ Sun Mar 19 21:53:29 2006
+++ linux-2.6.16/net/netlink/af_netlink.c Fri Apr 28 13:41:52 2006
@@ -61,7 +61,6 @@
#include <net/scm.h>
#include <net/netlink.h>
-#define Nprintk(a...)
#define NLGRPSZ(x) (ALIGN(x, sizeof(unsigned long) * 8) / 8)
struct netlink_sock {
^ 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