* Re: [PATCH NEXT 0/6] nexten: fixes and enhancements
From: David Miller @ 2009-09-07 8:54 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1252208592-2240-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sat, 5 Sep 2009 20:43:06 -0700
> Series of 6 driver enhancements / fixes, please apply to net-next-2.6.
All applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] wan: dlci/sdla transmit return dehacking
From: David Miller @ 2009-09-07 8:57 UTC (permalink / raw)
To: shemminger; +Cc: khc, sfr, linux-next, netdev
In-Reply-To: <20090904083346.43885303@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 4 Sep 2009 08:33:46 -0700
> This is a brute force removal of the wierd slave interface done for DLCI -> SDLA
> transmit. Before it was using non-standard return values and freeing skb in caller.
> This changes it to using normal return values, and freeing in the callee.
> Luckly only one driver pair was doing this. Not tested on real hardware,
> in fact I wonder if this driver pair is even being used by any users.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Irregardless of what we should do with the SDLA driver, this patch
should go in while that code is still in the tree.
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] net: fix hydra printk format warning
From: David Miller @ 2009-09-07 8:57 UTC (permalink / raw)
To: randy.dunlap; +Cc: linux-m68k, netdev, geert, zippel
In-Reply-To: <20090904172037.b2dd7f20.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Fri, 4 Sep 2009 17:20:37 -0700
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> m68k:
> drivers/net/hydra.c:178: warning: format '%08lx' expects type 'long unsigned int', but argument 3 has type 'resource_size_t'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* [net-next-2.6, 1/2] be2net: Changes to support flashing of the be2 network adapter
From: David Miller @ 2009-09-07 8:58 UTC (permalink / raw)
To: ajitk; +Cc: netdev
Both patches applied, thanks.
^ permalink raw reply
* Re: [PATCH] WAN: remove deprecated PCI_DEVICE_ID from PCI200SYN driver.
From: David Miller @ 2009-09-07 8:58 UTC (permalink / raw)
To: khc; +Cc: netdev
In-Reply-To: <m3ljktek61.fsf@intrepid.localdomain>
From: Krzysztof Halasa <khc@pm.waw.pl>
Date: Sat, 05 Sep 2009 12:54:30 +0200
> PCI200SYN has its own PCI subsystem device ID for 3+ years, now it's
> time to remove the generic PLX905[02] ID from the driver. Anyone with
> old EEPROM data will have to run the upgrade.
>
> Having the generic PLX905[02] (PCI-local bus bridge) ID is harmful
> as the driver tries to handle other devices based on these bridges.
>
> Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: Staging: cpc-usb CAN driver TODO list
From: Wolfgang Grandegger @ 2009-09-07 8:58 UTC (permalink / raw)
To: Sebastian Haas; +Cc: Oliver Hartkopp, Greg KH, Linux Netdev List, Felipe Balbi
In-Reply-To: <4AA4BDE6.7000707@ems-wuensche.com>
On 09/07/2009 10:01 AM, Sebastian Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Wolfgang,
>
> Wolfgang Grandegger schrieb:
>> Hi Sebastian,
>>
>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Oliver,
>>>
>>> I'm not yet sure how to actually start the development. There is so much
>>> to do, and I've not much time to spend on this, unfortunately. Because
>>> of this I can't rewrite the whole driver on my own in order to get a
>>> Socket-CAN driver but I can provide support, review patches, rent
>>> devices and make tests here.
>>>
>>> Oliver, you are not familiar with USB and I'm not very familiar with CAN
>>> netdev internals, why not combining these twos. You are writing the CAN
>>> part and write the USB part.
>>>
>>> I'll also write a specification which contains any information you need
>>> to develop a CAN driver for the device (commands, sequences, error
>>> handling).
>>
>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>> Note that we do a lot of Socket-CAN work in our free time, which is a
>> limited resource. Progress depends on funding to a certain extend.
> Money is also a limited resource. ;-)
>
> Let's become serious again, I know and respect that many of Socket-CAN
> and the Staging developers spend their free time working on it. We will
> of course work on the driver, but since we've not much time it may take
> several months. If someone wants to help, we would be very glad and
> happy to support the person as far as we can with devices, answers and
> tests.
OK, no problem. I really appreciate your support for Socket-CAN so far.
Thanks,
Wolfgang.
^ permalink raw reply
* Re: [PATCH] IXP42x HSS support for setting internal clock rate
From: David Miller @ 2009-09-07 8:59 UTC (permalink / raw)
To: khc; +Cc: netdev
In-Reply-To: <m3ab19cx0q.fsf@intrepid.localdomain>
From: Krzysztof Halasa <khc@pm.waw.pl>
Date: Sat, 05 Sep 2009 15:59:49 +0200
> HSS usually uses external clocks, so it's not a big deal. Internal clock
> is used for direct DTE-DTE connections and when the DCE doesn't provide
> it's own clock.
>
> This also depends on the oscillator frequency. Intel seems to have
> calculated the clock register settings for 33.33 MHz (66.66 MHz timer
> base). Their settings seem quite suboptimal both in terms of average
> frequency (60 ppm is unacceptable for G.703 applications, their primary
> intended usage(?)) and jitter.
>
> Many (most?) platforms use a 33.333 MHz oscillator, a 10 ppm difference
> from Intel's base.
>
> Instead of creating static tables, I've created a procedure to program
> the HSS clock register. The register consists of 3 parts (A, B, C).
> The average frequency (= bit rate) is:
> 66.66x MHz / (A + (B + 1) / (C + 1))
> The procedure aims at the closest average frequency, possibly at the
> cost of increased jitter. Nobody would be able to directly drive an
> unbufferred transmitter with a HSS anyway, and the frequency error is
> what it really counts.
...
> Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
Applied, thanks Krzysztof.
^ permalink raw reply
* [PATCH 07/12 v2] gigaset: improve error recovery
From: Tilman Schmidt @ 2009-09-07 8:59 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
i4ldeveloper-JX7+OpRa80SjiSfgN6Y1Ib39b6g2fGNp
Cc: Daniel Walker, Hansjoerg Lipp
In-Reply-To: <20090906-patch-gigaset-07.tilman-ZTO5kqT2PaM@public.gmane.org>
When the Gigaset base stops responding, try resetting the USB
connection to recover.
Impact: error handling improvement
Signed-off-by: Tilman Schmidt <tilman-ZTO5kqT2PaM@public.gmane.org>
---
drivers/isdn/gigaset/bas-gigaset.c | 69 +++++++++++++++++++++++------------
1 files changed, 45 insertions(+), 24 deletions(-)
diff --git a/drivers/isdn/gigaset/bas-gigaset.c b/drivers/isdn/gigaset/bas-gigaset.c
index 9e7108a..44bcfd9 100644
--- a/drivers/isdn/gigaset/bas-gigaset.c
+++ b/drivers/isdn/gigaset/bas-gigaset.c
@@ -134,6 +134,7 @@ struct bas_cardstate {
#define BS_ATRDPEND 0x040 /* urb_cmd_in in use */
#define BS_ATWRPEND 0x080 /* urb_cmd_out in use */
#define BS_SUSPEND 0x100 /* USB port suspended */
+#define BS_RESETTING 0x200 /* waiting for HD_RESET_INTERRUPT_PIPE_ACK */
static struct gigaset_driver *driver = NULL;
@@ -319,6 +320,21 @@ static int gigaset_set_line_ctrl(struct cardstate *cs, unsigned cflag)
return -EINVAL;
}
+/* set/clear bits in base connection state, return previous state
+ */
+static inline int update_basstate(struct bas_cardstate *ucs,
+ int set, int clear)
+{
+ unsigned long flags;
+ int state;
+
+ spin_lock_irqsave(&ucs->lock, flags);
+ state = ucs->basstate;
+ ucs->basstate = (state & ~clear) | set;
+ spin_unlock_irqrestore(&ucs->lock, flags);
+ return state;
+}
+
/* error_hangup
* hang up any existing connection because of an unrecoverable error
* This function may be called from any context and takes care of scheduling
@@ -350,12 +366,9 @@ static inline void error_hangup(struct bc_state *bcs)
*/
static inline void error_reset(struct cardstate *cs)
{
- /* close AT command channel to recover (ignore errors) */
- req_submit(cs->bcs, HD_CLOSE_ATCHANNEL, 0, BAS_TIMEOUT);
-
- //FIXME try to recover without bothering the user
- dev_err(cs->dev,
- "unrecoverable error - please disconnect Gigaset base to reset\n");
+ /* reset interrupt pipe to recover (ignore errors) */
+ update_basstate(cs->hw.bas, BS_RESETTING, 0);
+ req_submit(cs->bcs, HD_RESET_INTERRUPT_PIPE, 0, BAS_TIMEOUT);
}
/* check_pending
@@ -398,8 +411,13 @@ static void check_pending(struct bas_cardstate *ucs)
case HD_DEVICE_INIT_ACK: /* no reply expected */
ucs->pending = 0;
break;
- /* HD_READ_ATMESSAGE, HD_WRITE_ATMESSAGE, HD_RESET_INTERRUPTPIPE
- * are handled separately and should never end up here
+ case HD_RESET_INTERRUPT_PIPE:
+ if (!(ucs->basstate & BS_RESETTING))
+ ucs->pending = 0;
+ break;
+ /*
+ * HD_READ_ATMESSAGE and HD_WRITE_ATMESSAGE are handled separately
+ * and should never end up here
*/
default:
dev_warn(&ucs->interface->dev,
@@ -449,21 +467,6 @@ static void cmd_in_timeout(unsigned long data)
error_reset(cs);
}
-/* set/clear bits in base connection state, return previous state
- */
-inline static int update_basstate(struct bas_cardstate *ucs,
- int set, int clear)
-{
- unsigned long flags;
- int state;
-
- spin_lock_irqsave(&ucs->lock, flags);
- state = ucs->basstate;
- ucs->basstate = (state & ~clear) | set;
- spin_unlock_irqrestore(&ucs->lock, flags);
- return state;
-}
-
/* read_ctrl_callback
* USB completion handler for control pipe input
* called by the USB subsystem in interrupt context
@@ -762,7 +765,8 @@ static void read_int_callback(struct urb *urb)
break;
case HD_RESET_INTERRUPT_PIPE_ACK:
- gig_dbg(DEBUG_USBREQ, "HD_RESET_INTERRUPT_PIPE_ACK");
+ update_basstate(ucs, 0, BS_RESETTING);
+ dev_notice(cs->dev, "interrupt pipe reset\n");
break;
case HD_SUSPEND_END:
@@ -1429,6 +1433,7 @@ static void req_timeout(unsigned long data)
case HD_CLOSE_ATCHANNEL:
dev_err(bcs->cs->dev, "timeout closing AT channel\n");
+ error_reset(bcs->cs);
break;
case HD_CLOSE_B2CHANNEL:
@@ -1438,6 +1443,13 @@ static void req_timeout(unsigned long data)
error_reset(bcs->cs);
break;
+ case HD_RESET_INTERRUPT_PIPE:
+ /* error recovery escalation */
+ dev_err(bcs->cs->dev,
+ "reset interrupt pipe timeout, attempting USB reset\n");
+ usb_queue_reset_device(bcs->cs->hw.bas->interface);
+ break;
+
default:
dev_warn(bcs->cs->dev, "request 0x%02x timed out, clearing\n",
pending);
@@ -1930,6 +1942,15 @@ static int gigaset_write_cmd(struct cardstate *cs,
goto notqueued;
}
+ /* translate "+++" escape sequence sent as a single separate command
+ * into "close AT channel" command for error recovery
+ * The next command will reopen the AT channel automatically.
+ */
+ if (len == 3 && !memcmp(buf, "+++", 3)) {
+ rc = req_submit(cs->bcs, HD_CLOSE_ATCHANNEL, 0, BAS_TIMEOUT);
+ goto notqueued;
+ }
+
if (len > IF_WRITEBUF)
len = IF_WRITEBUF;
if (!(cb = kmalloc(sizeof(struct cmdbuf_t) + len, GFP_ATOMIC))) {
--
1.6.2.1.214.ge986c
^ permalink raw reply related
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: David Miller @ 2009-09-07 9:00 UTC (permalink / raw)
To: tilman; +Cc: linux-kernel, netdev, i4ldeveloper, hjlipp
In-Reply-To: <20090906-patch-gigaset-00.tilman@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Sun, 6 Sep 2009 20:58:52 +0200 (CEST)
> Would you please take these into your net tree for 2.6.32.
So do we have an ISDN maintainer or not?
If Karsten is still maintaining things, your work should
go through him not me.
This also applies to the 4 part CAPI patch set you sent as
well.
I'm tossing these from patchwork as they're not my realm.
:-)
^ permalink raw reply
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: Tilman Schmidt @ 2009-09-07 9:07 UTC (permalink / raw)
To: Daniel Walker; +Cc: davem, linux-kernel, netdev, i4ldeveloper, Hansjoerg Lipp
In-Reply-To: <1252286806.2139.1.camel@desktop>
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
Daniel,
thanks for taking a look at my patches.
On Sun, 06 Sep 2009 18:26:46 -0700, Daniel Walker wrote:
> patches 6,7,10, and 12 all have checkpatch errors. Could you fix those?
I have reissued patch 7, exchanging the "static" and "inline" keywords
as requested.
The other patches I'd much prefer to keep as they are. The "ERRORs"
checkpatch.pl reported for them are results of keeping to the existing
formatting of the patched files. Completely reformatting them would
cloud the actual changes made by the patches.
Thanks,
Tilman
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: Tilman Schmidt @ 2009-09-07 9:11 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev, i4ldeveloper, hjlipp
In-Reply-To: <20090907.020038.248900438.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 896 bytes --]
David Miller schrieb:
> From: Tilman Schmidt <tilman@imap.cc>
> Date: Sun, 6 Sep 2009 20:58:52 +0200 (CEST)
>
>> Would you please take these into your net tree for 2.6.32.
>
> So do we have an ISDN maintainer or not?
>
> If Karsten is still maintaining things, your work should
> go through him not me.
Last atime I asked, you said me you would take ISDN patches.
Could you two please sort this out? I am just a humble driver
maintainer knowing nothing about maintainer politics.
> This also applies to the 4 part CAPI patch set you sent as
> well.
>
> I'm tossing these from patchwork as they're not my realm.
> :-)
I guess I have no recourse against that.
:-(
T.
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: David Miller @ 2009-09-07 9:18 UTC (permalink / raw)
To: tilman; +Cc: linux-kernel, netdev, i4ldeveloper, hjlipp, isdn
In-Reply-To: <4AA4CE49.7040501@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Mon, 07 Sep 2009 11:11:37 +0200
> David Miller schrieb:
>> From: Tilman Schmidt <tilman@imap.cc>
>> Date: Sun, 6 Sep 2009 20:58:52 +0200 (CEST)
>>
>>> Would you please take these into your net tree for 2.6.32.
>>
>> So do we have an ISDN maintainer or not?
>>
>> If Karsten is still maintaining things, your work should
>> go through him not me.
>
> Last atime I asked, you said me you would take ISDN patches.
> Could you two please sort this out?
Sure.
Karsten, are you going to handle ISDN and ISDN driver patches
and queue them up to me?
> I am just a humble driver maintainer knowing nothing about
> maintainer politics.
Understood.
^ permalink raw reply
* Re: net_sched 00/07: classful multiqueue dummy scheduler
From: Jarek Poplawski @ 2009-09-07 9:46 UTC (permalink / raw)
To: David Miller; +Cc: kaber, netdev
In-Reply-To: <20090907.015039.154939751.davem@davemloft.net>
On 07-09-2009 10:50, David Miller wrote:
> I gave these patches a very basic bashing with NIU, and it
> seems to work from what I've tried.
>
> I know that Jarek has expressed some questions about the callback
> scheme used by the new mq classful qdisc, as well as some other
> issues, but we can refine this using followon patches.
>
> For now I'm pushing this out so that it gets wider testing.
Sure, it should make the further discussion easier (at least until
a new backward compatibilty starts to matter ;-).
Thanks,
Jarek P.
^ permalink raw reply
* [PATCH 2.6.31-rc9] mv643xx_eth.c: remove unused txq_set_wrr()
From: Mikael Pettersson @ 2009-09-07 9:59 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: linux-kernel, netdev
The txq_set_wrr() function in drivers/net/mv643xx_eth.c is
unused, not even referenced under #if 0 or something like that,
which results in a compile-time warning:
drivers/net/mv643xx_eth.c:1070: warning: 'txq_set_wrr' defined but not used
Fix: remove it.
Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
---
drivers/net/mv643xx_eth.c | 34 ----------------------------------
1 file changed, 34 deletions(-)
--- linux-2.6.31-rc9/drivers/net/mv643xx_eth.c.~1~ 2009-09-06 12:20:57.000000000 +0200
+++ linux-2.6.31-rc9/drivers/net/mv643xx_eth.c 2009-09-07 11:36:32.000000000 +0200
@@ -1066,40 +1066,6 @@ static void txq_set_fixed_prio_mode(stru
}
}
-static void txq_set_wrr(struct tx_queue *txq, int weight)
-{
- struct mv643xx_eth_private *mp = txq_to_mp(txq);
- int off;
- u32 val;
-
- /*
- * Turn off fixed priority mode.
- */
- off = 0;
- switch (mp->shared->tx_bw_control) {
- case TX_BW_CONTROL_OLD_LAYOUT:
- off = TXQ_FIX_PRIO_CONF;
- break;
- case TX_BW_CONTROL_NEW_LAYOUT:
- off = TXQ_FIX_PRIO_CONF_MOVED;
- break;
- }
-
- if (off) {
- val = rdlp(mp, off);
- val &= ~(1 << txq->index);
- wrlp(mp, off, val);
-
- /*
- * Configure WRR weight for this queue.
- */
-
- val = rdlp(mp, off);
- val = (val & ~0xff) | (weight & 0xff);
- wrlp(mp, TXQ_BW_WRR_CONF(txq->index), val);
- }
-}
-
/* mii management interface *************************************************/
static irqreturn_t mv643xx_eth_err_irq(int irq, void *dev_id)
^ permalink raw reply
* Re: Staging: cpc-usb CAN driver TODO list
From: Oliver Hartkopp @ 2009-09-07 10:10 UTC (permalink / raw)
To: Sebastian Haas
Cc: Wolfgang Grandegger, Greg KH, Linux Netdev List, Felipe Balbi
In-Reply-To: <4AA4CB3F.3060200@grandegger.com>
Wolfgang Grandegger wrote:
> On 09/07/2009 10:01 AM, Sebastian Haas wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Wolfgang,
>>
>> Wolfgang Grandegger schrieb:
>>> Hi Sebastian,
>>>
>>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Oliver,
>>>>
>>>> I'm not yet sure how to actually start the development. There is so
>>>> much
>>>> to do, and I've not much time to spend on this, unfortunately. Because
>>>> of this I can't rewrite the whole driver on my own in order to get a
>>>> Socket-CAN driver but I can provide support, review patches, rent
>>>> devices and make tests here.
>>>>
>>>> Oliver, you are not familiar with USB and I'm not very familiar with
>>>> CAN
>>>> netdev internals, why not combining these twos. You are writing the CAN
>>>> part and write the USB part.
>>>>
>>>> I'll also write a specification which contains any information you need
>>>> to develop a CAN driver for the device (commands, sequences, error
>>>> handling).
>>>
>>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>>> Note that we do a lot of Socket-CAN work in our free time, which is a
>>> limited resource. Progress depends on funding to a certain extend.
>> Money is also a limited resource. ;-)
>>
>> Let's become serious again, I know and respect that many of Socket-CAN
>> and the Staging developers spend their free time working on it. We will
>> of course work on the driver, but since we've not much time it may take
>> several months. If someone wants to help, we would be very glad and
>> happy to support the person as far as we can with devices, answers and
>> tests.
>
> OK, no problem. I really appreciate your support for Socket-CAN so far.
Indeed. Me too.
I tried to take a second look into cpc-usb_drv.c and i would suggest to remove
all the procfs and the chardev stuff and then create a CAN netdev when you
identified an USB node analogue to
/* Detect available channels */
for (i = 0; i < EMS_PCMCIA_MAX_CHAN; i++) {
dev = alloc_sja1000dev(0);
if (dev == NULL) {
err = -ENOMEM;
goto failure_cleanup;
}
card->net_dev[i] = dev;
priv = netdev_priv(dev);
priv->priv = card;
SET_NETDEV_DEV(dev, &pdev->dev);
as you know from your ems_pcmcia.c driver
and
struct net_device *alloc_sja1000dev(int sizeof_priv)
{
struct net_device *dev;
struct sja1000_priv *priv;
dev = alloc_candev(sizeof(struct sja1000_priv) + sizeof_priv);
if (!dev)
return NULL;
priv = netdev_priv(dev);
priv->dev = dev;
priv->can.bittiming_const = &sja1000_bittiming_const;
priv->can.do_set_bittiming = sja1000_set_bittiming;
priv->can.do_set_mode = sja1000_set_mode;
if (sizeof_priv)
priv->priv = (void *)priv + sizeof(struct sja1000_priv);
return dev;
}
as you know from the sja1000.c (which can probably be used for the
LPC2119_PRODUCT_ID we should try to implement first).
Then we need something like this stuff
static const struct net_device_ops sja1000_netdev_ops = {
.ndo_open = sja1000_open,
.ndo_stop = sja1000_close,
.ndo_start_xmit = sja1000_start_xmit,
};
int register_sja1000dev(struct net_device *dev)
{
if (!sja1000_probe_chip(dev))
return -ENODEV;
dev->netdev_ops = &sja1000_netdev_ops;
dev->flags |= IFF_ECHO; /* we support local echo */
set_reset_mode(dev);
chipset_init(dev);
return register_candev(dev);
}
from sja1000.c
And then we have an USB CAN node that has a belonging CAN netdevice (maybe
there is something else we can look at that's used in other USB ethernet
adapters).
I know from the PEAK USB driver at
http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver.6.11.tar.gz
that i just needed to duplicate and modify the usb rx/tx stuff and redirect
the CAN frames into the network stack. But this PEAK driver does not have a
netlink configuration interface and can only be taken as a limited example ...
I assume, when the driver (cpc_usb.c or ems_usb.c analogue to the ems_pcmcia.c
?) is prepared as described above, one can go and connect the rx/tx dataflow
and the netlink configuration.
Unfortunately i'm short of time the next two weeks but maybe you can start and
create such a new C-file (probably based on ems_pcmcia.c) ?
Best regards,
Oliver
^ permalink raw reply
* Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
From: Michael S. Tsirkin @ 2009-09-07 10:15 UTC (permalink / raw)
To: Ira W. Snyder
Cc: netdev, virtualization, kvm, linux-kernel, mingo, linux-mm, akpm,
hpa, gregory.haskins, Rusty Russell, s.hetze
In-Reply-To: <20090903183945.GF28651@ovro.caltech.edu>
On Thu, Sep 03, 2009 at 11:39:45AM -0700, Ira W. Snyder wrote:
> On Thu, Aug 27, 2009 at 07:07:50PM +0300, Michael S. Tsirkin wrote:
> > What it is: vhost net is a character device that can be used to reduce
> > the number of system calls involved in virtio networking.
> > Existing virtio net code is used in the guest without modification.
> >
> > There's similarity with vringfd, with some differences and reduced scope
> > - uses eventfd for signalling
> > - structures can be moved around in memory at any time (good for migration)
> > - support memory table and not just an offset (needed for kvm)
> >
> > common virtio related code has been put in a separate file vhost.c and
> > can be made into a separate module if/when more backends appear. I used
> > Rusty's lguest.c as the source for developing this part : this supplied
> > me with witty comments I wouldn't be able to write myself.
> >
> > What it is not: vhost net is not a bus, and not a generic new system
> > call. No assumptions are made on how guest performs hypercalls.
> > Userspace hypervisors are supported as well as kvm.
> >
> > How it works: Basically, we connect virtio frontend (configured by
> > userspace) to a backend. The backend could be a network device, or a
> > tun-like device. In this version I only support raw socket as a backend,
> > which can be bound to e.g. SR IOV, or to macvlan device. Backend is
> > also configured by userspace, including vlan/mac etc.
> >
> > Status:
> > This works for me, and I haven't see any crashes.
> > I have done some light benchmarking (with v4), compared to userspace, I
> > see improved latency (as I save up to 4 system calls per packet) but not
> > bandwidth/CPU (as TSO and interrupt mitigation are not supported). For
> > ping benchmark (where there's no TSO) troughput is also improved.
> >
> > Features that I plan to look at in the future:
> > - tap support
> > - TSO
> > - interrupt mitigation
> > - zero copy
> >
>
> Hello Michael,
>
> I've started looking at vhost with the intention of using it over PCI to
> connect physical machines together.
>
> The part that I am struggling with the most is figuring out which parts
> of the rings are in the host's memory, and which parts are in the
> guest's memory.
All rings are in guest's memory, to match existing virtio code. vhost
assumes that the memory space of the hypervisor userspace process covers
the whole of guest memory. And there's a translation table.
Ring addresses are userspace addresses, they do not undergo translation.
> If I understand everything correctly, the rings are all userspace
> addresses, which means that they can be moved around in physical memory,
> and get pushed out to swap.
Unless they are locked, yes.
> AFAIK, this is impossible to handle when
> connecting two physical systems, you'd need the rings available in IO
> memory (PCI memory), so you can ioreadXX() them instead. To the best of
> my knowledge, I shouldn't be using copy_to_user() on an __iomem address.
> Also, having them migrate around in memory would be a bad thing.
>
> Also, I'm having trouble figuring out how the packet contents are
> actually copied from one system to the other. Could you point this out
> for me?
The code in net/packet/af_packet.c does it when vhost calls sendmsg.
> Is there somewhere I can find the userspace code (kvm, qemu, lguest,
> etc.) code needed for interacting with the vhost misc device so I can
> get a better idea of how userspace is supposed to work?
Look in archives for kvm@vger.kernel.org. the subject is qemu-kvm: vhost net.
> (Features
> negotiation, etc.)
>
> Thanks,
> Ira
That's not yet implemented as there are no features yet. I'm working on
tap support, which will add a feature bit. Overall, qemu does an ioctl
to query supported features, and then acks them with another ioctl. I'm
also trying to avoid duplicating functionality available elsewhere. So
that to check e.g. TSO support, you'd just look at the underlying
hardware device you are binding to.
--
MST
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/2] Add an alternative cs89x0 driver
From: Sascha Hauer @ 2009-09-07 10:24 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: netdev
In-Reply-To: <20090826104634.GA14425@e-circ.dyndns.org>
Hi Kurt,
On Wed, Aug 26, 2009 at 12:46:34PM +0200, Kurt Van Dijck wrote:
> Hi Sacha,
>
> I'm using a 2.6.25.
> Converting to your platform_device based driver,
> I needed to configure the irq (see patch, irq flags).
> Looking in the old cs89x0.c, it's done in the driver. Should I have
> configured the irq level elsewhere? Or is this patch valid to do?
This is the way to go. I don't know if the cs89x0 has configurable
interrupt levels though.
Sascha
>
> Kurt
>
> Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
> ---
> Index: drivers/net/cirrus-cs89x0.c
> ===================================================================
> --- drivers/net/cirrus-cs89x0.c (revision 7107)
> +++ drivers/net/cirrus-cs89x0.c (working copy)
> @@ -487,7 +487,8 @@
> }
>
> /* install interrupt handler */
> - result = request_irq(ndev->irq, &cirrus_interrupt, 0, ndev->name, ndev);
> + result = request_irq(ndev->irq, &cirrus_interrupt,
> + IRQF_TRIGGER_HIGH, ndev->name, ndev);
> if (result < 0) {
> printk(KERN_ERR "%s: could not register interrupt %d\n",
> ndev->name, ndev->irq);
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: Staging: cpc-usb CAN driver TODO list
From: Wolfgang Grandegger @ 2009-09-07 10:27 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: Sebastian Haas, Greg KH, Linux Netdev List, Felipe Balbi
In-Reply-To: <4AA4DC09.8070803@hartkopp.net>
On 09/07/2009 12:10 PM, Oliver Hartkopp wrote:
> Wolfgang Grandegger wrote:
>> On 09/07/2009 10:01 AM, Sebastian Haas wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Wolfgang,
>>>
>>> Wolfgang Grandegger schrieb:
>>>> Hi Sebastian,
>>>>
>>>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Oliver,
>>>>>
>>>>> I'm not yet sure how to actually start the development. There is so
>>>>> much
>>>>> to do, and I've not much time to spend on this, unfortunately. Because
>>>>> of this I can't rewrite the whole driver on my own in order to get a
>>>>> Socket-CAN driver but I can provide support, review patches, rent
>>>>> devices and make tests here.
>>>>>
>>>>> Oliver, you are not familiar with USB and I'm not very familiar with
>>>>> CAN
>>>>> netdev internals, why not combining these twos. You are writing the CAN
>>>>> part and write the USB part.
>>>>>
>>>>> I'll also write a specification which contains any information you need
>>>>> to develop a CAN driver for the device (commands, sequences, error
>>>>> handling).
>>>>
>>>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>>>> Note that we do a lot of Socket-CAN work in our free time, which is a
>>>> limited resource. Progress depends on funding to a certain extend.
>>> Money is also a limited resource. ;-)
>>>
>>> Let's become serious again, I know and respect that many of Socket-CAN
>>> and the Staging developers spend their free time working on it. We will
>>> of course work on the driver, but since we've not much time it may take
>>> several months. If someone wants to help, we would be very glad and
>>> happy to support the person as far as we can with devices, answers and
>>> tests.
>>
>> OK, no problem. I really appreciate your support for Socket-CAN so far.
>
> Indeed. Me too.
>
> I tried to take a second look into cpc-usb_drv.c and i would suggest to remove
> all the procfs and the chardev stuff and then create a CAN netdev when you
> identified an USB node analogue to
>
> /* Detect available channels */
> for (i = 0; i< EMS_PCMCIA_MAX_CHAN; i++) {
> dev = alloc_sja1000dev(0);
> if (dev == NULL) {
> err = -ENOMEM;
> goto failure_cleanup;
> }
>
> card->net_dev[i] = dev;
> priv = netdev_priv(dev);
> priv->priv = card;
> SET_NETDEV_DEV(dev,&pdev->dev);
>
> as you know from your ems_pcmcia.c driver
>
> and
>
> struct net_device *alloc_sja1000dev(int sizeof_priv)
> {
> struct net_device *dev;
> struct sja1000_priv *priv;
>
> dev = alloc_candev(sizeof(struct sja1000_priv) + sizeof_priv);
> if (!dev)
> return NULL;
>
> priv = netdev_priv(dev);
>
> priv->dev = dev;
> priv->can.bittiming_const =&sja1000_bittiming_const;
> priv->can.do_set_bittiming = sja1000_set_bittiming;
> priv->can.do_set_mode = sja1000_set_mode;
>
> if (sizeof_priv)
> priv->priv = (void *)priv + sizeof(struct sja1000_priv);
>
> return dev;
> }
>
> as you know from the sja1000.c (which can probably be used for the
> LPC2119_PRODUCT_ID we should try to implement first).
>
> Then we need something like this stuff
>
> static const struct net_device_ops sja1000_netdev_ops = {
> .ndo_open = sja1000_open,
> .ndo_stop = sja1000_close,
> .ndo_start_xmit = sja1000_start_xmit,
> };
>
> int register_sja1000dev(struct net_device *dev)
> {
> if (!sja1000_probe_chip(dev))
> return -ENODEV;
>
> dev->netdev_ops =&sja1000_netdev_ops;
>
> dev->flags |= IFF_ECHO; /* we support local echo */
>
> set_reset_mode(dev);
> chipset_init(dev);
>
> return register_candev(dev);
> }
>
> from sja1000.c
>
> And then we have an USB CAN node that has a belonging CAN netdevice (maybe
> there is something else we can look at that's used in other USB ethernet
> adapters).
>
> I know from the PEAK USB driver at
>
> http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver.6.11.tar.gz
>
> that i just needed to duplicate and modify the usb rx/tx stuff and redirect
> the CAN frames into the network stack. But this PEAK driver does not have a
> netlink configuration interface and can only be taken as a limited example ...
>
> I assume, when the driver (cpc_usb.c or ems_usb.c analogue to the ems_pcmcia.c
> ?) is prepared as described above, one can go and connect the rx/tx dataflow
> and the netlink configuration.
>
> Unfortunately i'm short of time the next two weeks but maybe you can start and
> create such a new C-file (probably based on ems_pcmcia.c) ?
Also, there are USB network driver in "drivers/net/usb/" which might
serve as examples.
Wolfgang.
^ permalink raw reply
* Re: Staging: cpc-usb CAN driver TODO list
From: Sebastian Haas @ 2009-09-07 11:06 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Wolfgang Grandegger, Greg KH, Linux Netdev List, Felipe Balbi
In-Reply-To: <4AA4DC09.8070803@hartkopp.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Okay, thanks for the tips. Lets see what I can create today.
Sebastian
Oliver Hartkopp schrieb:
> Wolfgang Grandegger wrote:
>> On 09/07/2009 10:01 AM, Sebastian Haas wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Wolfgang,
>>>
>>> Wolfgang Grandegger schrieb:
>>>> Hi Sebastian,
>>>>
>>>> On 09/07/2009 07:56 AM, Sebastian Haas wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Oliver,
>>>>>
>>>>> I'm not yet sure how to actually start the development. There is so
>>>>> much
>>>>> to do, and I've not much time to spend on this, unfortunately. Because
>>>>> of this I can't rewrite the whole driver on my own in order to get a
>>>>> Socket-CAN driver but I can provide support, review patches, rent
>>>>> devices and make tests here.
>>>>>
>>>>> Oliver, you are not familiar with USB and I'm not very familiar with
>>>>> CAN
>>>>> netdev internals, why not combining these twos. You are writing the CAN
>>>>> part and write the USB part.
>>>>>
>>>>> I'll also write a specification which contains any information you need
>>>>> to develop a CAN driver for the device (commands, sequences, error
>>>>> handling).
>>>> Alternatively, EMS Wuensche could also hire an expert doing the job ;-).
>>>> Note that we do a lot of Socket-CAN work in our free time, which is a
>>>> limited resource. Progress depends on funding to a certain extend.
>>> Money is also a limited resource. ;-)
>>>
>>> Let's become serious again, I know and respect that many of Socket-CAN
>>> and the Staging developers spend their free time working on it. We will
>>> of course work on the driver, but since we've not much time it may take
>>> several months. If someone wants to help, we would be very glad and
>>> happy to support the person as far as we can with devices, answers and
>>> tests.
>> OK, no problem. I really appreciate your support for Socket-CAN so far.
>
> Indeed. Me too.
>
> I tried to take a second look into cpc-usb_drv.c and i would suggest to remove
> all the procfs and the chardev stuff and then create a CAN netdev when you
> identified an USB node analogue to
>
> /* Detect available channels */
> for (i = 0; i < EMS_PCMCIA_MAX_CHAN; i++) {
> dev = alloc_sja1000dev(0);
> if (dev == NULL) {
> err = -ENOMEM;
> goto failure_cleanup;
> }
>
> card->net_dev[i] = dev;
> priv = netdev_priv(dev);
> priv->priv = card;
> SET_NETDEV_DEV(dev, &pdev->dev);
>
> as you know from your ems_pcmcia.c driver
>
> and
>
> struct net_device *alloc_sja1000dev(int sizeof_priv)
> {
> struct net_device *dev;
> struct sja1000_priv *priv;
>
> dev = alloc_candev(sizeof(struct sja1000_priv) + sizeof_priv);
> if (!dev)
> return NULL;
>
> priv = netdev_priv(dev);
>
> priv->dev = dev;
> priv->can.bittiming_const = &sja1000_bittiming_const;
> priv->can.do_set_bittiming = sja1000_set_bittiming;
> priv->can.do_set_mode = sja1000_set_mode;
>
> if (sizeof_priv)
> priv->priv = (void *)priv + sizeof(struct sja1000_priv);
>
> return dev;
> }
>
> as you know from the sja1000.c (which can probably be used for the
> LPC2119_PRODUCT_ID we should try to implement first).
>
> Then we need something like this stuff
>
> static const struct net_device_ops sja1000_netdev_ops = {
> .ndo_open = sja1000_open,
> .ndo_stop = sja1000_close,
> .ndo_start_xmit = sja1000_start_xmit,
> };
>
> int register_sja1000dev(struct net_device *dev)
> {
> if (!sja1000_probe_chip(dev))
> return -ENODEV;
>
> dev->netdev_ops = &sja1000_netdev_ops;
>
> dev->flags |= IFF_ECHO; /* we support local echo */
>
> set_reset_mode(dev);
> chipset_init(dev);
>
> return register_candev(dev);
> }
>
> from sja1000.c
>
> And then we have an USB CAN node that has a belonging CAN netdevice (maybe
> there is something else we can look at that's used in other USB ethernet
> adapters).
>
> I know from the PEAK USB driver at
>
> http://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver.6.11.tar.gz
>
> that i just needed to duplicate and modify the usb rx/tx stuff and redirect
> the CAN frames into the network stack. But this PEAK driver does not have a
> netlink configuration interface and can only be taken as a limited example ...
>
> I assume, when the driver (cpc_usb.c or ems_usb.c analogue to the ems_pcmcia.c
> ?) is prepared as described above, one can go and connect the rx/tx dataflow
> and the netlink configuration.
>
> Unfortunately i'm short of time the next two weeks but maybe you can start and
> create such a new C-file (probably based on ems_pcmcia.c) ?
>
> Best regards,
> Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqk6TcACgkQpqRB8PJG7XzpQACePuMXFX6pSg7EyssTNnDfVomv
Lm0AnA7WKWLHfRny2iF5krEaT966WmPJ
=07pa
-----END PGP SIGNATURE-----
--
EMS Dr. Thomas Wuensche e.K.
Sonnenhang 3
85304 Ilmmuenster
HRA Neuburg a.d. Donau, HR-Nr. 70.106
Phone: +49-8441-490260
Fax : +49-8441-81860
http://www.ems-wuensche.com
^ permalink raw reply
* Re: [PATCH 1/2] Add an alternative cs89x0 driver
From: Kurt Van Dijck @ 2009-09-07 12:35 UTC (permalink / raw)
To: Sascha Hauer; +Cc: netdev
In-Reply-To: <20090907102434.GC31592@pengutronix.de>
On Mon, Sep 07, 2009 at 12:24:34PM +0200, Sascha Hauer wrote:
> Date: Mon, 7 Sep 2009 12:24:34 +0200
> Subject: Re: [PATCH 1/2] Add an alternative cs89x0 driver
> From: Sascha Hauer <s.hauer@pengutronix.de>
> To: Kurt Van Dijck <kurt.van.dijck@eia.be>
> Cc: netdev@vger.kernel.org
> List-ID: <netdev.vger.kernel.org>
>
> Hi Kurt,
>
> On Wed, Aug 26, 2009 at 12:46:34PM +0200, Kurt Van Dijck wrote:
> > Hi Sacha,
> >
> > I'm using a 2.6.25.
> > Converting to your platform_device based driver,
> > I needed to configure the irq (see patch, irq flags).
> > Looking in the old cs89x0.c, it's done in the driver. Should I have
> > configured the irq level elsewhere? Or is this patch valid to do?
>
> This is the way to go. I don't know if the cs89x0 has configurable
> interrupt levels though.
I haven't read any spec about cs89x0, but by looking in the existing
code:
1) IRQF_TRIGGER_HIGH seems like the default
2) the old driver didn't do any irq config in the chip either.
May I assume you were lucky testing the driver on a platform that had
IRQF_TRIGGER_HIGH per default?
I have it running (with patch) on a iMX31 (arm)
Kurt
>
> Sascha
>
> >
> > Kurt
> >
> > Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
> > ---
> > Index: drivers/net/cirrus-cs89x0.c
> > ===================================================================
> > --- drivers/net/cirrus-cs89x0.c (revision 7107)
> > +++ drivers/net/cirrus-cs89x0.c (working copy)
> > @@ -487,7 +487,8 @@
> > }
> >
> > /* install interrupt handler */
> > - result = request_irq(ndev->irq, &cirrus_interrupt, 0, ndev->name, ndev);
> > + result = request_irq(ndev->irq, &cirrus_interrupt,
> > + IRQF_TRIGGER_HIGH, ndev->name, ndev);
> > if (result < 0) {
> > printk(KERN_ERR "%s: could not register interrupt %d\n",
> > ndev->name, ndev->irq);
> >
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> --
> 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] headers: net/ipv[46]/protocol.c header trim
From: Alexey Dobriyan @ 2009-09-07 12:38 UTC (permalink / raw)
To: davem; +Cc: netdev
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
net/ipv4/protocol.c | 19 ++-----------------
net/ipv6/protocol.c | 15 ++-------------
2 files changed, 4 insertions(+), 30 deletions(-)
--- a/net/ipv4/protocol.c
+++ b/net/ipv4/protocol.c
@@ -22,26 +22,11 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
-
-#include <asm/uaccess.h>
-#include <asm/system.h>
+#include <linux/cache.h>
#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <linux/string.h>
-#include <linux/socket.h>
-#include <linux/in.h>
-#include <linux/inet.h>
#include <linux/netdevice.h>
-#include <linux/timer.h>
-#include <net/ip.h>
+#include <linux/spinlock.h>
#include <net/protocol.h>
-#include <linux/skbuff.h>
-#include <net/sock.h>
-#include <net/icmp.h>
-#include <net/udp.h>
-#include <net/ipip.h>
-#include <linux/igmp.h>
struct net_protocol *inet_protos[MAX_INET_PROTOS] ____cacheline_aligned_in_smp;
static DEFINE_SPINLOCK(inet_proto_lock);
--- a/net/ipv6/protocol.c
+++ b/net/ipv6/protocol.c
@@ -20,20 +20,9 @@
* - Removed unused variable 'inet6_protocol_base'
* - Modified inet6_del_protocol() to correctly maintain copy bit.
*/
-
-#include <linux/errno.h>
-#include <linux/types.h>
-#include <linux/socket.h>
-#include <linux/sockios.h>
-#include <linux/net.h>
-#include <linux/in6.h>
+#include <linux/module.h>
#include <linux/netdevice.h>
-#include <linux/if_arp.h>
-
-#include <net/sock.h>
-#include <net/snmp.h>
-
-#include <net/ipv6.h>
+#include <linux/spinlock.h>
#include <net/protocol.h>
struct inet6_protocol *inet6_protos[MAX_INET_PROTOS];
^ permalink raw reply
* Re: [iproute2] tc action mirred question
From: Xiaofei Wu @ 2009-09-07 12:38 UTC (permalink / raw)
To: hadi; +Cc: linux netdev
In-Reply-To: <1252260806.4580.6.camel@dogo.mojatatu.com>
>> On node A,
>> wlan0, IP address 192.168.1.1/24 ; wlan1, IP address 192.168.2.1/24
>> I use command 'tc filter add dev wlan0 ... match ip src 192.168.1.0/24 ...
>> action mirred egress mirror dev wlan1' to mirror packets.
>> When I use 'tcpdump -i wlan1', I can 'see' the packets 'A(wlan0)->B' (node B will forward them to C).
>> How to forward the mirroring packets 'A(wlan1)' to D (then, node D forwards them to C) ?
>>
>>
>Is there a trick to this question or is it too basic? ;->
I am sorry.
Maybe it is very easy for you. But I didn't find enough documents(or examples) about 'tc' to help me.
I just want to know:
1) Could I forward the mirroring packets to another node ,and then route it to the destination(if I use
iproute2 (ip, tc ...) )? I described my purpose in my last email.
2) After I mirrored the packets, I should use 'ip route' , 'ip rule' to modify route tables. Is this right?
>You should repeat the same on wlan1 to mirror to wlan0 i.e on wlan1:
>match ip src 192.168.2.0/24 ...
>action mirred egress mirror dev wlan0
Would this cause loops?
>Note the node C will receive "wrong" src mac addresses on those
>interfaces; you may want to correct/edit them first before you send them
>out. Look at using the pedit action.
Regards,
Wu
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: introduce primary_passive option
From: Jiri Pirko @ 2009-09-07 12:50 UTC (permalink / raw)
To: Nicolas de Pesloüan; +Cc: netdev, davem, fubar, bonding-devel
In-Reply-To: <4AA01F65.7010408@free.fr>
Thu, Sep 03, 2009 at 09:56:21PM CEST, nicolas.2p.debian@free.fr wrote:
> Jiri Pirko wrote:
>> (updated)
>>
>> In some cases there is not desirable to switch back to primary interface when
>> it's link recovers and rather stay with currently active one. We need to avoid
>> packetloss as much as we can in some cases. This is solved by introducing
>> primary_passive option. Note that enslaved primary slave is set as current
>> active no matter what.
>>
>> This patch depends on the following one:
>> [net-next-2.6] bonding: make ab_arp select active slaves as other modes
>> http://patchwork.ozlabs.org/patch/32684/
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>>
>> diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
>> index d5181ce..e70fa8e 100644
>> --- a/Documentation/networking/bonding.txt
>> +++ b/Documentation/networking/bonding.txt
>> @@ -614,6 +614,17 @@ primary
>> The primary option is only valid for active-backup mode.
>> +primary_passive
>> +
>> + Specifies the behaviour of the primary slave in case of
>> + it's link recovery has been detected. By default (value 0) the
>> + primary slave is set as active slave immediately after the link
>> + recovery. If the value is 1 or 2 then current active slave doesn't
>> + change as long as it's link status doesn't change. This prevents
>> + the bonding device from flip-flopping. Plus if the value is 1 this
>> + behaviour happens only if the speed and duplex of primary slave is
>> + higher. It the value is 2 then it happens everytime.
>> +
>
> May I suggest the following option name and description instead ?
>
> -----
>
> primary_return
>
> Specifies the behavior of the current active slave when the primary was
> down and comes back up. This option is designed to prevent flip-flopping
> between the primary slave and other slaves. The possible values and
> their respective effects are:
>
> alway or 0 (default)
>
> The primary slave becomes the active slave whenever it comes
> back up.
>
> better or 1
>
> The primary slave becomes the active slave when it comes back
> up, if the speed and duplex of the primary slave is better
> than the speed and duplex of the current active slave.
>
> failure_only or 2
>
> The primary slave becomes the active slave only if the current
> active slave fails and the primary slave is up.
>
> When no slave are active, if the primary comes back up, it becomes the
> active slave, regardless of the value of primary_return.
>
> -----
>
> Then, to allow those logical names, I suggest you use the
> bond_parse_parm() function and the following constants and struct, to
> parse module params and sysfs configuration.
>
> enum {
> BOND_PRI_RETURN_ALWAYS = 0,
> BOND_PRI_RETURN_BETTER = 1,
> BOND_PRI_RETURN_FAILURE_ONLY = 2,
> };
>
> const struct bond_parm_tbl bond_pri_return_tbl[] = {
> { "always", BOND_PRI_RETURN_ALWAYS},
> { "better", BOND_PRI_RETURN_BETTER},
> { "failure_only", BOND_PRI_RETURN_FAILURE_ONLY},
> { NULL, -1},
> };
>
> Nicolas.
Ok, I like this, but I would stay rather with Jay's suggestion to call this
option primary_passive. Seems more accurate to me.
I'm going to repost soon.
Jirka
>
>> updelay
>> Specifies the time, in milliseconds, to wait before enabling a
>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>> index 699bfdd..65066c1 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>> @@ -94,6 +94,7 @@ static int downdelay;
>> static int use_carrier = 1;
>> static char *mode;
>> static char *primary;
>> +static int primary_passive;
>> static char *lacp_rate;
>> static char *ad_select;
>> static char *xmit_hash_policy;
>> @@ -126,6 +127,9 @@ MODULE_PARM_DESC(mode, "Mode of operation : 0 for balance-rr, "
>> "6 for balance-alb");
>> module_param(primary, charp, 0);
>> MODULE_PARM_DESC(primary, "Primary network device to use");
>> +module_param(primary_passive, int, 0);
>> +MODULE_PARM_DESC(primary_passive, "Do not set primary slave active once it comes up; "
>> + "0 for off (default), 1 for on only if speed of primary is not higher, 2 for on");
>> module_param(lacp_rate, charp, 0);
>> MODULE_PARM_DESC(lacp_rate, "LACPDU tx rate to request from 802.3ad partner "
>> "(slow/fast)");
>> @@ -1070,6 +1074,25 @@ out:
>> }
>> +static bool bond_should_loose_active(struct bonding *bond)
>> +{
>> + struct slave *prim = bond->primary_slave;
>> + struct slave *curr = bond->curr_active_slave;
>> +
>> + if (!prim || !curr || curr->link != BOND_LINK_UP)
>> + return true;
>> + if (bond->force_primary) {
>> + bond->force_primary = false;
>> + return true;
>> + }
>> + if (bond->params.primary_passive == 1 &&
>> + (prim->speed < curr->speed ||
>> + (prim->speed == curr->speed && prim->duplex <= curr->duplex)))
>> + return false;
>> + if (bond->params.primary_passive == 2)
>> + return false;
>> + return true;
>> +}
>> /**
>> * find_best_interface - select the best available slave to be the active one
>> @@ -1094,7 +1117,8 @@ static struct slave *bond_find_best_slave(struct bonding *bond)
>> }
>> if ((bond->primary_slave) &&
>> - bond->primary_slave->link == BOND_LINK_UP) {
>> + bond->primary_slave->link == BOND_LINK_UP &&
>> + bond_should_loose_active(bond)) {
>> new_active = bond->primary_slave;
>> }
>> @@ -1675,8 +1699,10 @@ int bond_enslave(struct net_device *bond_dev,
>> struct net_device *slave_dev)
>> if (USES_PRIMARY(bond->params.mode) && bond->params.primary[0]) {
>> /* if there is a primary slave, remember it */
>> - if (strcmp(bond->params.primary, new_slave->dev->name) == 0)
>> + if (strcmp(bond->params.primary, new_slave->dev->name) == 0) {
>> bond->primary_slave = new_slave;
>> + bond->force_primary = true;
>> + }
>> }
>> write_lock_bh(&bond->curr_slave_lock);
>> @@ -4942,6 +4968,18 @@ static int bond_check_params(struct bond_params *params)
>> primary = NULL;
>> }
>> + if (primary) {
>> + if ((primary_passive != 0) && (primary_passive != 1) &&
>> + (primary_passive != 2)) {
>> + pr_warning(DRV_NAME
>> + ": Warning: primary_passive module parameter "
>> + "(%d), not of valid value (0/1/2), so it was "
>> + "set to 0\n",
>> + primary_passive);
>> + primary_passive = 0;
>> + }
>> + }
>> +
>> if (fail_over_mac) {
>> fail_over_mac_value = bond_parse_parm(fail_over_mac,
>> fail_over_mac_tbl);
>> @@ -4973,6 +5011,7 @@ static int bond_check_params(struct bond_params *params)
>> params->use_carrier = use_carrier;
>> params->lacp_fast = lacp_fast;
>> params->primary[0] = 0;
>> + params->primary_passive = primary_passive;
>> params->fail_over_mac = fail_over_mac_value;
>> if (primary) {
>> diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
>> index 6044e12..e813d48 100644
>> --- a/drivers/net/bonding/bond_sysfs.c
>> +++ b/drivers/net/bonding/bond_sysfs.c
>> @@ -1212,6 +1212,59 @@ static DEVICE_ATTR(primary, S_IRUGO | S_IWUSR,
>> bonding_show_primary, bonding_store_primary);
>> /*
>> + * Show and set the primary_passive flag.
>> + */
>> +static ssize_t bonding_show_primary_passive(struct device *d,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct bonding *bond = to_bond(d);
>> +
>> + return sprintf(buf, "%d\n", bond->params.primary_passive);
>> +}
>> +
>> +static ssize_t bonding_store_primary_passive(struct device *d,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + int new_value, ret = count;
>> + struct bonding *bond = to_bond(d);
>> +
>> + if (!rtnl_trylock())
>> + return restart_syscall();
>> +
>> + if (sscanf(buf, "%d", &new_value) != 1) {
>> + pr_err(DRV_NAME
>> + ": %s: no primary_passive value specified.\n",
>> + bond->dev->name);
>> + ret = -EINVAL;
>> + goto out;
>> + }
>> + if (new_value == 0 || new_value == 1 || new_value == 2) {
>> + bond->params.primary_passive = new_value;
>> + pr_info(DRV_NAME ": %s: Setting primary_passive to %d.\n",
>> + bond->dev->name, new_value);
>> + if (new_value == 0 || new_value == 1) {
>> + bond->force_primary = true;
>> + read_lock(&bond->lock);
>> + write_lock_bh(&bond->curr_slave_lock);
>> + bond_select_active_slave(bond);
>> + write_unlock_bh(&bond->curr_slave_lock);
>> + read_unlock(&bond->lock);
>> + }
>> + } else {
>> + pr_info(DRV_NAME
>> + ": %s: Ignoring invalid primary_passive value %d.\n",
>> + bond->dev->name, new_value);
>> + }
>> +out:
>> + rtnl_unlock();
>> + return count;
>> +}
>> +static DEVICE_ATTR(primary_passive, S_IRUGO | S_IWUSR,
>> + bonding_show_primary_passive, bonding_store_primary_passive);
>> +
>> +/*
>> * Show and set the use_carrier flag.
>> */
>> static ssize_t bonding_show_carrier(struct device *d,
>> @@ -1500,6 +1553,7 @@ static struct attribute *per_bond_attrs[] = {
>> &dev_attr_num_unsol_na.attr,
>> &dev_attr_miimon.attr,
>> &dev_attr_primary.attr,
>> + &dev_attr_primary_passive.attr,
>> &dev_attr_use_carrier.attr,
>> &dev_attr_active_slave.attr,
>> &dev_attr_mii_status.attr,
>> diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
>> index 6290a50..b6287e0 100644
>> --- a/drivers/net/bonding/bonding.h
>> +++ b/drivers/net/bonding/bonding.h
>> @@ -131,6 +131,7 @@ struct bond_params {
>> int lacp_fast;
>> int ad_select;
>> char primary[IFNAMSIZ];
>> + int primary_passive;
>> __be32 arp_targets[BOND_MAX_ARP_TARGETS];
>> };
>> @@ -190,6 +191,7 @@ struct bonding {
>> struct slave *curr_active_slave;
>> struct slave *current_arp_slave;
>> struct slave *primary_slave;
>> + bool force_primary;
>> s32 slave_cnt; /* never change this value outside the attach/detach wrappers */
>> rwlock_t lock;
>> rwlock_t curr_slave_lock;
>>
>
^ permalink raw reply
* Re: net_sched 00/07: classful multiqueue dummy scheduler
From: Eric Dumazet @ 2009-09-07 13:00 UTC (permalink / raw)
To: David Miller; +Cc: kaber, netdev
In-Reply-To: <20090907.015039.154939751.davem@davemloft.net>
David Miller a écrit :
> I gave these patches a very basic bashing with NIU, and it
> seems to work from what I've tried.
>
> I know that Jarek has expressed some questions about the callback
> scheme used by the new mq classful qdisc, as well as some other
> issues, but we can refine this using followon patches.
>
> For now I'm pushing this out so that it gets wider testing.
>
> Thanks everyone!
Very interesting :)
Had very litle time to test this, but got problems very fast, if rate estimator configured.
(Here, eth2 maps to tg3, that uses a num_tx_queues of 5, even on non multiqueue device)
So its real_num_tx_queues is 1, but we can play with tc and mq
# tc qdisc replace dev eth2 handle 1: root estimator 1sec 8sec mq
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 62414 bytes 401 pkt (dropped 0, overlimits 0 requeues 0)
rate 5456bit 4pps backlog 0b 0p requeues 0
# tc qdisc replace dev eth2 parent 1:1 estimator 1sec 8sec pfifo
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 12984 bytes 88 pkt (dropped 0, overlimits 0 requeues 0)
rate 4368bit 4pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 12984 bytes 88 pkt (dropped 0, overlimits 0 requeues 0)
rate 9624bit 8pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 36781 bytes 244 pkt (dropped 0, overlimits 0 requeues 0)
rate 34360Mbit 205872pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 36781 bytes 244 pkt (dropped 0, overlimits 0 requeues 0)
rate 19824bit 16pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 52663 bytes 348 pkt (dropped 0, overlimits 0 requeues 0)
rate 17457Mbit 105605pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 52663 bytes 348 pkt (dropped 0, overlimits 0 requeues 0)
rate 22560bit 19pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 71775 bytes 473 pkt (dropped 0, overlimits 0 requeues 0)
rate 11838Mbit 47402pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 71775 bytes 473 pkt (dropped 0, overlimits 0 requeues 0)
rate 23880bit 20pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 94755 bytes 623 pkt (dropped 0, overlimits 0 requeues 0)
rate 3562Mbit 18621pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 94755 bytes 623 pkt (dropped 0, overlimits 0 requeues 0)
rate 24440bit 20pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 112501 bytes 741 pkt (dropped 0, overlimits 0 requeues 0)
rate 734270Kbit 9562pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 112501 bytes 741 pkt (dropped 0, overlimits 0 requeues 0)
rate 24632bit 20pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 127137 bytes 836 pkt (dropped 0, overlimits 0 requeues 0)
rate 25390Mbit 4913pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 127137 bytes 836 pkt (dropped 0, overlimits 0 requeues 0)
rate 24960bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 150745 bytes 992 pkt (dropped 0, overlimits 0 requeues 0)
rate 6212Mbit 1693pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 150745 bytes 992 pkt (dropped 0, overlimits 0 requeues 0)
rate 25032bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 174008 bytes 1144 pkt (dropped 0, overlimits 0 requeues 0)
rate 29377Mbit 674pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 174008 bytes 1144 pkt (dropped 0, overlimits 0 requeues 0)
rate 24904bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 185976 bytes 1224 pkt (dropped 0, overlimits 0 requeues 0)
rate 13093Mbit 408pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 185976 bytes 1224 pkt (dropped 0, overlimits 0 requeues 0)
rate 25288bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 232272 bytes 1530 pkt (dropped 0, overlimits 0 requeues 0)
rate 5196Mbit 57pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 232272 bytes 1530 pkt (dropped 0, overlimits 0 requeues 0)
rate 24784bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 300071 bytes 1977 pkt (dropped 0, overlimits 0 requeues 0)
rate 8988Mbit 6pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 300071 bytes 1977 pkt (dropped 0, overlimits 0 requeues 0)
rate 24432bit 20pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 377495 bytes 2490 pkt (dropped 0, overlimits 0 requeues 0)
rate 20429Mbit 2pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 377495 bytes 2490 pkt (dropped 0, overlimits 0 requeues 0)
rate 24520bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 448070 bytes 2958 pkt (dropped 0, overlimits 0 requeues 0)
rate 5726Mbit 4pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 448070 bytes 2958 pkt (dropped 0, overlimits 0 requeues 0)
rate 24576bit 20pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 519926 bytes 3435 pkt (dropped 0, overlimits 0 requeues 0)
rate 265505Kbit 3pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 519926 bytes 3435 pkt (dropped 0, overlimits 0 requeues 0)
rate 24920bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 522242 bytes 3449 pkt (dropped 0, overlimits 0 requeues 0)
rate 232389Kbit 62pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 522242 bytes 3449 pkt (dropped 0, overlimits 0 requeues 0)
rate 25304bit 21pps backlog 0b 0p requeues 0
# tc -s -d qdisc show dev eth2
qdisc mq 1: root
Sent 528702 bytes 3491 pkt (dropped 0, overlimits 0 requeues 0)
rate 177925Kbit 49pps backlog 0b 0p requeues 0
qdisc pfifo 8001: parent 1:1 limit 1000p
Sent 528702 bytes 3491 pkt (dropped 0, overlimits 0 requeues 0)
rate 25400bit 21pps backlog 0b 0p requeues 0
<<<crash>>>
(On another term I had a "ping -i 0.1 192.168.20.120" that gave :
2009/08/07 14:53:42.498 64 bytes from 192.168.20.120: icmp_seq=1982 ttl=64 time=0.126 ms
2009/08/07 14:53:42.598 64 bytes from 192.168.20.120: icmp_seq=1983 ttl=64 time=0.118 ms
2009/08/07 14:53:42.698 64 bytes from 192.168.20.120: icmp_seq=1984 ttl=64 time=0.114 ms
2009/08/07 14:53:42.798 64 bytes from 192.168.20.120: icmp_seq=1985 ttl=64 time=0.123 ms
2009/08/07 14:53:42.898 64 bytes from 192.168.20.120: icmp_seq=1986 ttl=64 time=0.126 ms
2009/08/07 14:53:42.998 64 bytes from 192.168.20.120: icmp_seq=1987 ttl=64 time=0.119 ms
2009/08/07 14:53:43.098 64 bytes from 192.168.20.120: icmp_seq=1988 ttl=64 time=0.122 ms
2009/08/07 14:53:43.198 64 bytes from 192.168.20.120: icmp_seq=1989 ttl=64 time=0.119 ms
2009/08/07 14:53:43.298 64 bytes from 192.168.20.120: icmp_seq=1990 ttl=64 time=0.117 ms
2009/08/07 14:53:43.398 64 bytes from 192.168.20.120: icmp_seq=1991 ttl=64 time=0.117 ms
ping: sendmsg: No buffer space available
^ permalink raw reply
* Re: [iproute2] tc action mirred question
From: jamal @ 2009-09-07 12:54 UTC (permalink / raw)
To: Xiaofei Wu; +Cc: linux netdev
In-Reply-To: <749852.6581.qm@web111606.mail.gq1.yahoo.com>
On Mon, 2009-09-07 at 05:38 -0700, Xiaofei Wu wrote:
> I just want to know:
> 1) Could I forward the mirroring packets to another node ,and then route it to the destination(if I use
> iproute2 (ip, tc ...) )? I described my purpose in my last email.
Yes, you can mirror to another node(B/D). To route on that node(B/D),
your dst MAC address has to be correct for that destination node(B/D) to
accept it. You could try to run the destination node in promisc mode
and you may be able to get away without changing dst mac.
> 2) After I mirrored the packets, I should use 'ip route' , 'ip rule' to modify route tables. Is this right?
>
Assuming you are talking about B/D, yes you can do routing there if the
node accepts it..
> >You should repeat the same on wlan1 to mirror to wlan0 i.e on wlan1:
> >match ip src 192.168.2.0/24 ...
> >action mirred egress mirror dev wlan0
>
> Would this cause loops?
>
Ok, so this was the trick question;->
I dont see how the loop would happen - they are different "match" rules
i.e one is for 192.168.2.0/24 and the other is for 192.168.1.0/24
Whether it loops or not is easy for you to verify.
cheers,
jamal
^ 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