* Re: [PATCH net-next 0/9] bnx2x: FCoE support
From: David Miller @ 2010-12-16 19:43 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong, dmitry, shmulikr
In-Reply-To: <1292255013.631.48.camel@lb-tlvb-vladz>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Mon, 13 Dec 2010 17:43:33 +0200
> This patch-series adds FCoE support to 57712 HW. It provides
> required intefaces for upper-level driver (CNIC) and handles
> FCoE related HW/FW initialization and flows.
>
> Since the FW files are too big (patches 6 and 8) and will not
> pass the mailing list, it is also located at:
> http://linux.broadcom.com/eilong/1.62.00-2
>
> It's a second attempt to submit this patch series after fixing
> a Tx hash distribution fairness.
Applied.
^ permalink raw reply
* RE: [PATCH] e1000e: workaround missing power down mii control bit on 82571
From: Allan, Bruce W @ 2010-12-16 19:28 UTC (permalink / raw)
To: Allan, Bruce W, Ben Hutchings, Arthur Jones
Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A9001773F7655@orsmsx509.amr.corp.intel.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of Allan, Bruce W
>Sent: Thursday, December 16, 2010 11:04 AM
>To: Ben Hutchings; Arthur Jones
>Cc: Kirsher, Jeffrey T; netdev@vger.kernel.org
>Subject: RE: [PATCH] e1000e: workaround missing power down mii control bit on
>82571
>
>>-----Original Message-----
>>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>>Behalf Of Ben Hutchings
>>Sent: Thursday, December 16, 2010 10:57 AM
>>To: Arthur Jones
>>Cc: Kirsher, Jeffrey T; netdev@vger.kernel.org
>>Subject: Re: [PATCH] e1000e: workaround missing power down mii control bit on
>>82571
>>
>>Adding this special case into MDIO access seems like a really nasty
>>hack. Surely the callers that set the control register should take care
>>of this.
>>
>>Ben.
>
>Agreed. I am setting up to repro now to see if it is an actual hardware
>issue or just a software bug; either way, this patch is not the correct
>approach and I'll follow up shortly.
>
>Bruce.
It's the reset in e1000_set_settings() which ignores that we had previously
powered off the Phy. I'll go through the rest of the code and fix up this
and any other occurrences of similar issues properly.
Thanks for reporting this issue Arthur.
Bruce.
^ permalink raw reply
* Re: pktgen IP address stepping
From: Joe Perches @ 2010-12-16 19:18 UTC (permalink / raw)
To: Kristian Larsson; +Cc: David S. Miller, netdev
In-Reply-To: <20101216183004.GC8404@spritelink.se>
On Thu, 2010-12-16 at 19:30 +0100, Kristian Larsson wrote:
> > I suggest using actual ipv4 addresses (and ipv6 if you ever
> > need it) as increment/mask.
> Not sure I follow you, should the stepping be specified as
> 0.0.0.213 if I would like to increase with 213 or 0.0.255.255 if
> I want to increase by a /16 at a time?
More like:
Initial IPv4 address: 0.0.0.1
Step: 0.1.0.0
Mask: 127.0.0.1
addr = (addr + step) & mask;
Cycles through all /16's below 128
^ permalink raw reply
* [PATCH] ehea: Fixing some message level
From: leitao @ 2010-12-16 19:13 UTC (permalink / raw)
To: davem; +Cc: netdev, Breno Leitao
Currently there are some info message that is set as error, and an error
message that is set as debug. This patch just fixes it.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
---
drivers/net/ehea/ehea_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 0dfef6d..1032b5b 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -740,13 +740,13 @@ static int ehea_proc_rwqes(struct net_device *dev,
skb_arr_rq1_len,
wqe_index);
if (unlikely(!skb)) {
- netif_err(port, rx_err, dev,
+ netif_info(port, rx_err, dev,
"LL rq1: skb=NULL\n");
skb = netdev_alloc_skb(dev,
EHEA_L_PKT_SIZE);
if (!skb) {
- netdev_info(dev, "Not enough memory to allocate skb\n");
+ netdev_err(dev, "Not enough memory to allocate skb\n");
break;
}
}
--
1.7.1
^ permalink raw reply related
* RE: [PATCH] e1000e: workaround missing power down mii control bit on 82571
From: Allan, Bruce W @ 2010-12-16 19:04 UTC (permalink / raw)
To: Ben Hutchings, Arthur Jones; +Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org
In-Reply-To: <1292525797.3253.8.camel@bwh-desktop>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of Ben Hutchings
>Sent: Thursday, December 16, 2010 10:57 AM
>To: Arthur Jones
>Cc: Kirsher, Jeffrey T; netdev@vger.kernel.org
>Subject: Re: [PATCH] e1000e: workaround missing power down mii control bit on
>82571
>
>On Thu, 2010-12-16 at 10:28 -0800, Arthur Jones wrote:
>> Hi Jeff, Re-sending w/ proper netdev email
>> address. Sorry about that...
>>
>> Arthur
>>
>> ---
>>
>> On 82571 only, AFAICT, the PHY does not seem to
>> store the MII control register 0 bit 11 (power
>> down PHY). So that when we power down the PHY
>> on dev_close() and then run ethtool on the closed
>> dev, we end up turning the PHY back on even though
>> the interface is down. This pretty easy to repro:
>>
>> $ ethtool -s eth0 wol d
>> $ ifconfig eth0 up
>> $ mii-tool eth0
>> eth0: negotiated 100baseTx-FD, link ok
>> $ ifconfig eth0 down
>> $ mii-tool eth0
>> eth0: no link
>> $ ethtool -s eth0 autoneg on (doesn't really matter what we do here)
>> $ mii-tool eth0
>> eth0: negotiated 100baseTx-FD, link ok (this should be: eth0: no link)
>>
>> We fix this by tracking the power down bit that we
>> write to the PHY control register and re-inserting
>> it when we read it.
>[...]
>
>Adding this special case into MDIO access seems like a really nasty
>hack. Surely the callers that set the control register should take care
>of this.
>
>Ben.
Agreed. I am setting up to repro now to see if it is an actual hardware
issue or just a software bug; either way, this patch is not the correct
approach and I'll follow up shortly.
Bruce.
^ permalink raw reply
* [PATCH net-next] pktgen: Remove unnecessary prefix from pr_<level>
From: Joe Perches @ 2010-12-16 19:02 UTC (permalink / raw)
To: Kristian Larsson; +Cc: David S. Miller, netdev
In-Reply-To: <20101216183004.GC8404@spritelink.se>
Remove "pktgen: " prefix string from one pr_info.
pr_fmt adds it, so this is a duplicate.
Signed-off-by: Joe Perches <joe@perches.com>
---
> > trivia:
> > pr_<foo> calls are already prefixed with pktgen via pr_fmt,
> > you don't need to add it to the format string.
> Same thing here, will look over it. I think I copied most of this
> from some other part of pktgen.c :)
net/core/pktgen.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 18fe20d..a9e7fc4 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3553,8 +3553,7 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)
break;
default: /* Drivers are not supposed to return other values! */
if (net_ratelimit())
- pr_info("pktgen: %s xmit error: %d\n",
- pkt_dev->odevname, ret);
+ pr_info("%s xmit error: %d\n", pkt_dev->odevname, ret);
pkt_dev->errors++;
/* fallthru */
case NETDEV_TX_LOCKED:
^ permalink raw reply related
* Re: [PATCH] e1000e: workaround missing power down mii control bit on 82571
From: Ben Hutchings @ 2010-12-16 18:56 UTC (permalink / raw)
To: Arthur Jones; +Cc: Jeff Kirsher, netdev
In-Reply-To: <20101216182847.GA14985@ajones-laptop.nbttech.com>
On Thu, 2010-12-16 at 10:28 -0800, Arthur Jones wrote:
> Hi Jeff, Re-sending w/ proper netdev email
> address. Sorry about that...
>
> Arthur
>
> ---
>
> On 82571 only, AFAICT, the PHY does not seem to
> store the MII control register 0 bit 11 (power
> down PHY). So that when we power down the PHY
> on dev_close() and then run ethtool on the closed
> dev, we end up turning the PHY back on even though
> the interface is down. This pretty easy to repro:
>
> $ ethtool -s eth0 wol d
> $ ifconfig eth0 up
> $ mii-tool eth0
> eth0: negotiated 100baseTx-FD, link ok
> $ ifconfig eth0 down
> $ mii-tool eth0
> eth0: no link
> $ ethtool -s eth0 autoneg on (doesn't really matter what we do here)
> $ mii-tool eth0
> eth0: negotiated 100baseTx-FD, link ok (this should be: eth0: no link)
>
> We fix this by tracking the power down bit that we
> write to the PHY control register and re-inserting
> it when we read it.
[...]
Adding this special case into MDIO access seems like a really nasty
hack. Surely the callers that set the control register should take care
of this.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] e1000e: workaround missing power down mii control bit on 82571
From: Arthur Jones @ 2010-12-16 18:28 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: netdev
Hi Jeff, Re-sending w/ proper netdev email
address. Sorry about that...
Arthur
---
On 82571 only, AFAICT, the PHY does not seem to
store the MII control register 0 bit 11 (power
down PHY). So that when we power down the PHY
on dev_close() and then run ethtool on the closed
dev, we end up turning the PHY back on even though
the interface is down. This pretty easy to repro:
$ ethtool -s eth0 wol d
$ ifconfig eth0 up
$ mii-tool eth0
eth0: negotiated 100baseTx-FD, link ok
$ ifconfig eth0 down
$ mii-tool eth0
eth0: no link
$ ethtool -s eth0 autoneg on (doesn't really matter what we do here)
$ mii-tool eth0
eth0: negotiated 100baseTx-FD, link ok (this should be: eth0: no link)
We fix this by tracking the power down bit that we
write to the PHY control register and re-inserting
it when we read it.
Signed-off-by: Arthur Jones <ajones@riverbed.com>
---
drivers/net/e1000e/hw.h | 1 +
drivers/net/e1000e/netdev.c | 1 +
drivers/net/e1000e/phy.c | 9 +++++++++
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000e/hw.h b/drivers/net/e1000e/hw.h
index ba302a5..34974f2 100644
--- a/drivers/net/e1000e/hw.h
+++ b/drivers/net/e1000e/hw.h
@@ -875,6 +875,7 @@ struct e1000_phy_info {
u16 cable_length;
u16 max_cable_length;
u16 min_cable_length;
+ u16 control_power_down;
u8 mdix;
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index c4ca162..ac81596 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -5781,6 +5781,7 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
hw->mac.ops.get_bus_info(&adapter->hw);
adapter->hw.phy.autoneg_wait_to_complete = 0;
+ adapter->hw.phy.control_power_down = 0;
/* Copper options */
if (adapter->hw.phy.media_type == e1000_media_type_copper) {
diff --git a/drivers/net/e1000e/phy.c b/drivers/net/e1000e/phy.c
index 3d3dc0c..55b9f78 100644
--- a/drivers/net/e1000e/phy.c
+++ b/drivers/net/e1000e/phy.c
@@ -224,6 +224,11 @@ s32 e1000e_read_phy_reg_mdic(struct e1000_hw *hw, u32 offset, u16 *data)
e_dbg("MDI Error\n");
return -E1000_ERR_PHY;
}
+
+ /* 82571 does not seem to store the power down bit (bit 11) */
+ if (offset == PHY_CONTROL && phy->type == e1000_phy_igp_2)
+ mdic |= phy->control_power_down;
+
*data = (u16) mdic;
return 0;
@@ -247,6 +252,10 @@ s32 e1000e_write_phy_reg_mdic(struct e1000_hw *hw, u32 offset, u16 data)
return -E1000_ERR_PARAM;
}
+ /* 82571 does not seem to store the power down bit (bit 11) */
+ if (offset == PHY_CONTROL && phy->type == e1000_phy_igp_2)
+ phy->control_power_down = data & MII_CR_POWER_DOWN;
+
/*
* Set up Op-code, Phy Address, and register offset in the MDI
* Control register. The MAC will take care of interfacing with the
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] via-velocity: fix the WOL bug on 1000M full duplex forced mode
From: Jan Ceuleers @ 2010-12-16 18:34 UTC (permalink / raw)
To: David Lv; +Cc: netdev, romieu
In-Reply-To: <AANLkTi=-MRrH1nCcbzqUMoP1sd=7opNGAz7KwmdoMmjA@mail.gmail.com>
On 16/12/10 10:33, David Lv wrote:
> This patch isn't based on the first patch of the sleep speed 10M.
> The VIA velocity card can't be waken up by WOL tool on 1000M full
> duplex forced mode.
> This patch fixes the bug.
> Thanks!
This patch is whitespace-damaged. Your previous version (14 December)
wasn't. Why did you resend? Is there a difference?
Thx, Jan
^ permalink raw reply
* Re: pktgen IP address stepping
From: David Miller @ 2010-12-16 18:34 UTC (permalink / raw)
To: kristian; +Cc: netdev
In-Reply-To: <20101216182724.GB8404@spritelink.se>
From: Kristian Larsson <kristian@spritelink.net>
Date: Thu, 16 Dec 2010 19:27:24 +0100
> And given your comment I suppose u32 is a better choice than
> "unsigned long", right?
Yes.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/1] can: c_can: Added support for Bosch C_CAN controller
From: David Miller @ 2010-12-16 18:31 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D0A5236.5070900-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
From: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Date: Thu, 16 Dec 2010 18:53:58 +0100
> On 12/16/2010 01:09 PM, Tomoya MORINAGA wrote:
>> On Thursday, December 16, 2010 6:11 PM, Wolfgang Grandegger wrote:
>>
>>> Ah, oh, I just realized that the register layout is almost identical to
>>> the recently accepted *pch_can* driver. Tomoya, does pch_can use a c_can
>>> core? Well, then it makes really sense to have a generic c_can driver
>>> for the SPEAR, PCH, etc. Board specific details are handled via platform
>>> definition. This driver already provides that functionality, IFAICS.
>>
>> Hi Wolfgang,
>>
>> It seems pch_can similar to c_can.
>> However, sorry, I don't know if pch_can core is the same as c_can since
>> LSI is provided by Intel.
>> If necessary, please contact to Intel.
>
> You could also try to use that driver. I'm rather sure that it does work
> on your hardware as well.
Indeed.
^ permalink raw reply
* Re: pktgen IP address stepping
From: Kristian Larsson @ 2010-12-16 18:30 UTC (permalink / raw)
To: Joe Perches; +Cc: David S. Miller, netdev
In-Reply-To: <1292522532.29894.33.camel@Joe-Laptop>
On Thu, Dec 16, 2010 at 10:02:12AM -0800, Joe Perches wrote:
> On Thu, 2010-12-16 at 18:28 +0100, Kristian Larsson wrote:
> > This patch adds the ability to set the step rate at which the source
> > or destination IP address is increased when src_min / src_max or
> > dst_min / dst_max is used with pktgen.
> > Usage is simple, two new parameters:
> > src_step X
> > dst_step X
> > where X is a positive integer (or actually an unsigned long long).
> []
> > Looking forward to any feedback and / or suggestions.
>
> I suggest using actual ipv4 addresses (and ipv6 if you ever
> need it) as increment/mask.
Not sure I follow you, should the stepping be specified as
0.0.0.213 if I would like to increase with 213 or 0.0.255.255 if
I want to increase by a /16 at a time?
> For your current use, __u32 would work fine.
Yepp, I'll have a look at that once I get home :)
> trivia:
>
> pr_<foo> calls are already prefixed with pktgen via pr_fmt,
> you don't need to add it to the format string.
Same thing here, will look over it. I think I copied most of this
from some other part of pktgen.c :)
Kind regards,
Kristian.
--
Kristian Larsson KLL-RIPE
+46 704 264511 kll@spritelink.net
^ permalink raw reply
* Re: pktgen IP address stepping
From: Kristian Larsson @ 2010-12-16 18:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20101216.094426.193723178.davem@davemloft.net>
On Thu, Dec 16, 2010 at 09:44:26AM -0800, David Miller wrote:
> From: Kristian Larsson <kristian@spritelink.net>
> Date: Thu, 16 Dec 2010 18:28:00 +0100
>
> > Looking forward to any feedback and / or suggestions.
>
> If you need a huge type for the step values in order to handle ipv6
> addresses or similar, used a fixed sized type such as "u64" instead of
> "unsigned long long".
It is not developed with IPv6 in mind, it actually doesn't touch
those parts of the code at all. Stepping through the IPv6 space
and incrementing by what would equal one /64 at a time is a
painfully slow process. We'd need all 128 bits there to make it
useful - an alternative would be to set the step length by prefix
mask instead, ie src6_step 16 would step through by increasing
one /16 at a time.
For IPv4 we could settle for less, something like 32 bits!? ;)
And given your comment I suppose u32 is a better choice than
"unsigned long", right?
I was actually looking at the IPv6 part and noticed how it
appears to lack the option to set a min and max address, only
random addresses. My intention was to write a patch for that too,
though later on and if I'm able :)
Kind regards,
Kristian.
--
Kristian Larsson KLL-RIPE
+46 704 264511 kll@spritelink.net
^ permalink raw reply
* Re: [PATCH net-next-2.6] Documentation/networking/l2tp.txt: update documentation.
From: David Shwatrz @ 2010-12-16 18:22 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev, jchapman
In-Reply-To: <20101215.111448.104060252.davem@davemloft.net>
Hi,
My intention was just to fix the documentation so it will reflect
the current situation, where you cannot use "ip l2tp", but there
is an alternative (though temporary probably). It could take
time till this will be available in iproute2. That's all.
DS
On Wed, Dec 15, 2010 at 9:14 PM, David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Wed, 15 Dec 2010 10:52:07 -0800
>
>> I wish you would stop whining about it and just reimplement
>> without using libnl as requested.
>
> Seriously.
>
> David, I'm not applying a patch where you complain about
> a problem which you have self-inflicted upon yourself.
>
> Stephen's request was beyond reasonable, and you're just
> being unnecessarily difficult.
>
^ permalink raw reply
* Re: pktgen IP address stepping
From: Joe Perches @ 2010-12-16 18:02 UTC (permalink / raw)
To: Kristian Larsson; +Cc: David S. Miller, netdev
In-Reply-To: <20101216172800.GA8404@spritelink.se>
On Thu, 2010-12-16 at 18:28 +0100, Kristian Larsson wrote:
> This patch adds the ability to set the step rate at which the source
> or destination IP address is increased when src_min / src_max or
> dst_min / dst_max is used with pktgen.
> Usage is simple, two new parameters:
> src_step X
> dst_step X
> where X is a positive integer (or actually an unsigned long long).
[]
> Looking forward to any feedback and / or suggestions.
I suggest using actual ipv4 addresses (and ipv6 if you ever
need it) as increment/mask.
For your current use, __u32 would work fine.
trivia:
pr_<foo> calls are already prefixed with pktgen via pr_fmt,
you don't need to add it to the format string.
^ permalink raw reply
* Re: [PATCH v3 net-next-2.6] netfilter: x_tables: dont block BH while reading counters
From: Stephen Hemminger @ 2010-12-16 17:57 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jesper Dangaard Brouer, Patrick McHardy, Arnaldo Carvalho de Melo,
Steven Rostedt, Alexander Duyck, netfilter-devel, netdev,
Peter P Waskiewicz Jr
In-Reply-To: <1292521986.2883.472.camel@edumazet-laptop>
On Thu, 16 Dec 2010 18:53:06 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> [PATCH v3 net-next-2.6] netfilter: x_tables: dont block BH while reading counters
>
> Using "iptables -L" with a lot of rules might have a too big BH latency.
> Jesper mentioned ~6 ms and worried of frame drops.
>
> Switch to a per_cpu seqcount scheme, so that taking a snapshot of
> counters doesnt need to block BH (for this cpu, but also other cpus).
>
> Reported-by: Jesper Dangaard Brouer <hawk@comx.dk>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
--
^ permalink raw reply
* Re: [PATCH v3 net-next-2.6] netfilter: x_tables: dont block BH while reading counters
From: Stephen Hemminger @ 2010-12-16 17:57 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jesper Dangaard Brouer, Patrick McHardy, Arnaldo Carvalho de Melo,
Steven Rostedt, Alexander Duyck, netfilter-devel, netdev,
Peter P Waskiewicz Jr
In-Reply-To: <1292521986.2883.472.camel@edumazet-laptop>
On Thu, 16 Dec 2010 18:53:06 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> @@ -759,7 +742,7 @@ static struct xt_counters *alloc_counters(const struct xt_table *table)
> * about).
> */
> countersize = sizeof(struct xt_counters) * private->number;
> - counters = vmalloc(countersize);
> + counters = vzalloc(countersize);
>
> if (counters == NULL)
> return ERR_PTR(-ENOMEM);
> @@ -1007,7 +990,7 @@ static int __do_replace(struct net *net, const char *name,
> struct arpt_entry *iter;
>
> ret = 0;
> - counters = vmalloc(num_counters * sizeof(struct xt_counters));
> + counters = vzalloc(num_counters * sizeof(struct xt_counters));
> if (!counters) {
> ret = -ENOMEM;
> goto out;
This seems like a different and unrelated change.
--
^ permalink raw reply
* Re: [PATCH V7 2/8] posix clocks: introduce a syscall for clock tuning.
From: Thomas Gleixner @ 2010-12-16 17:55 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
John Stultz, Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti
In-Reply-To: <a93ce18c2987f7e102bc2ff5b12130211c222ea7.1292512461.git.richard.cochran-3mrvs1K0uXizZXS1Dc/lvw@public.gmane.org>
On Thu, 16 Dec 2010, Richard Cochran wrote:
> A new syscall is introduced that allows tuning of a POSIX clock. The
> syscall is implemented for four architectures: arm, blackfin, powerpc,
> and x86.
Can you please split that patch into one providing the syscall itself
and for each architecture a separate one ?
Looks good otherwise.
Reviewed-by: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/1] can: c_can: Added support for Bosch C_CAN controller
From: Wolfgang Grandegger @ 2010-12-16 17:53 UTC (permalink / raw)
To: Tomoya MORINAGA
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <070E08D3134344CBB04FC2F201E778B7-c0cKtqp5df7I9507bXv2FdBPR1lH4CV8@public.gmane.org>
On 12/16/2010 01:09 PM, Tomoya MORINAGA wrote:
> On Thursday, December 16, 2010 6:11 PM, Wolfgang Grandegger wrote:
>
>> Ah, oh, I just realized that the register layout is almost identical to
>> the recently accepted *pch_can* driver. Tomoya, does pch_can use a c_can
>> core? Well, then it makes really sense to have a generic c_can driver
>> for the SPEAR, PCH, etc. Board specific details are handled via platform
>> definition. This driver already provides that functionality, IFAICS.
>
> Hi Wolfgang,
>
> It seems pch_can similar to c_can.
> However, sorry, I don't know if pch_can core is the same as c_can since
> LSI is provided by Intel.
> If necessary, please contact to Intel.
You could also try to use that driver. I'm rather sure that it does work
on your hardware as well.
Wolfgang.
^ permalink raw reply
* [PATCH v3 net-next-2.6] netfilter: x_tables: dont block BH while reading counters
From: Eric Dumazet @ 2010-12-16 17:53 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jesper Dangaard Brouer, Patrick McHardy, Arnaldo Carvalho de Melo,
Steven Rostedt, Alexander Duyck, netfilter-devel, netdev,
Peter P Waskiewicz Jr
In-Reply-To: <20101216093149.71f082c7@nehalam>
Le jeudi 16 décembre 2010 à 09:31 -0800, Stephen Hemminger a écrit :
> On Thu, 16 Dec 2010 17:53:56 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > spinlock_t lock;
> > + seqcount_t seq;
>
> Since lock and seqcount_t are associated together, why isn't this a seqlock instead?
>
Absolutely, I found this a bit later while preparing final patch.
Thanks !
[PATCH v3 net-next-2.6] netfilter: x_tables: dont block BH while reading counters
Using "iptables -L" with a lot of rules might have a too big BH latency.
Jesper mentioned ~6 ms and worried of frame drops.
Switch to a per_cpu seqcount scheme, so that taking a snapshot of
counters doesnt need to block BH (for this cpu, but also other cpus).
Reported-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/netfilter/x_tables.h | 10 +++---
net/ipv4/netfilter/arp_tables.c | 45 ++++++++-------------------
net/ipv4/netfilter/ip_tables.c | 45 ++++++++-------------------
net/ipv6/netfilter/ip6_tables.c | 45 ++++++++-------------------
4 files changed, 47 insertions(+), 98 deletions(-)
diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h
index 742bec0..6712e71 100644
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -472,7 +472,7 @@ extern void xt_free_table_info(struct xt_table_info *info);
* necessary for reading the counters.
*/
struct xt_info_lock {
- spinlock_t lock;
+ seqlock_t lock;
unsigned char readers;
};
DECLARE_PER_CPU(struct xt_info_lock, xt_info_locks);
@@ -497,7 +497,7 @@ static inline void xt_info_rdlock_bh(void)
local_bh_disable();
lock = &__get_cpu_var(xt_info_locks);
if (likely(!lock->readers++))
- spin_lock(&lock->lock);
+ write_seqlock(&lock->lock);
}
static inline void xt_info_rdunlock_bh(void)
@@ -505,7 +505,7 @@ static inline void xt_info_rdunlock_bh(void)
struct xt_info_lock *lock = &__get_cpu_var(xt_info_locks);
if (likely(!--lock->readers))
- spin_unlock(&lock->lock);
+ write_sequnlock(&lock->lock);
local_bh_enable();
}
@@ -516,12 +516,12 @@ static inline void xt_info_rdunlock_bh(void)
*/
static inline void xt_info_wrlock(unsigned int cpu)
{
- spin_lock(&per_cpu(xt_info_locks, cpu).lock);
+ write_seqlock(&per_cpu(xt_info_locks, cpu).lock);
}
static inline void xt_info_wrunlock(unsigned int cpu)
{
- spin_unlock(&per_cpu(xt_info_locks, cpu).lock);
+ write_sequnlock(&per_cpu(xt_info_locks, cpu).lock);
}
/*
diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c
index 3fac340..e855fff 100644
--- a/net/ipv4/netfilter/arp_tables.c
+++ b/net/ipv4/netfilter/arp_tables.c
@@ -710,42 +710,25 @@ static void get_counters(const struct xt_table_info *t,
struct arpt_entry *iter;
unsigned int cpu;
unsigned int i;
- unsigned int curcpu = get_cpu();
-
- /* Instead of clearing (by a previous call to memset())
- * the counters and using adds, we set the counters
- * with data used by 'current' CPU
- *
- * Bottom half has to be disabled to prevent deadlock
- * if new softirq were to run and call ipt_do_table
- */
- local_bh_disable();
- i = 0;
- xt_entry_foreach(iter, t->entries[curcpu], t->size) {
- SET_COUNTER(counters[i], iter->counters.bcnt,
- iter->counters.pcnt);
- ++i;
- }
- local_bh_enable();
- /* Processing counters from other cpus, we can let bottom half enabled,
- * (preemption is disabled)
- */
for_each_possible_cpu(cpu) {
- if (cpu == curcpu)
- continue;
+ seqlock_t *lock = &per_cpu(xt_info_locks, cpu).lock;
+
i = 0;
- local_bh_disable();
- xt_info_wrlock(cpu);
xt_entry_foreach(iter, t->entries[cpu], t->size) {
- ADD_COUNTER(counters[i], iter->counters.bcnt,
- iter->counters.pcnt);
+ u64 bcnt, pcnt;
+ unsigned int start;
+
+ do {
+ start = read_seqbegin(lock);
+ bcnt = iter->counters.bcnt;
+ pcnt = iter->counters.pcnt;
+ } while (read_seqretry(lock, start));
+
+ ADD_COUNTER(counters[i], bcnt, pcnt);
++i;
}
- xt_info_wrunlock(cpu);
- local_bh_enable();
}
- put_cpu();
}
static struct xt_counters *alloc_counters(const struct xt_table *table)
@@ -759,7 +742,7 @@ static struct xt_counters *alloc_counters(const struct xt_table *table)
* about).
*/
countersize = sizeof(struct xt_counters) * private->number;
- counters = vmalloc(countersize);
+ counters = vzalloc(countersize);
if (counters == NULL)
return ERR_PTR(-ENOMEM);
@@ -1007,7 +990,7 @@ static int __do_replace(struct net *net, const char *name,
struct arpt_entry *iter;
ret = 0;
- counters = vmalloc(num_counters * sizeof(struct xt_counters));
+ counters = vzalloc(num_counters * sizeof(struct xt_counters));
if (!counters) {
ret = -ENOMEM;
goto out;
diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
index a846d63..652efea 100644
--- a/net/ipv4/netfilter/ip_tables.c
+++ b/net/ipv4/netfilter/ip_tables.c
@@ -884,42 +884,25 @@ get_counters(const struct xt_table_info *t,
struct ipt_entry *iter;
unsigned int cpu;
unsigned int i;
- unsigned int curcpu = get_cpu();
-
- /* Instead of clearing (by a previous call to memset())
- * the counters and using adds, we set the counters
- * with data used by 'current' CPU.
- *
- * Bottom half has to be disabled to prevent deadlock
- * if new softirq were to run and call ipt_do_table
- */
- local_bh_disable();
- i = 0;
- xt_entry_foreach(iter, t->entries[curcpu], t->size) {
- SET_COUNTER(counters[i], iter->counters.bcnt,
- iter->counters.pcnt);
- ++i;
- }
- local_bh_enable();
- /* Processing counters from other cpus, we can let bottom half enabled,
- * (preemption is disabled)
- */
for_each_possible_cpu(cpu) {
- if (cpu == curcpu)
- continue;
+ seqlock_t *lock = &per_cpu(xt_info_locks, cpu).lock;
+
i = 0;
- local_bh_disable();
- xt_info_wrlock(cpu);
xt_entry_foreach(iter, t->entries[cpu], t->size) {
- ADD_COUNTER(counters[i], iter->counters.bcnt,
- iter->counters.pcnt);
+ u64 bcnt, pcnt;
+ unsigned int start;
+
+ do {
+ start = read_seqbegin(lock);
+ bcnt = iter->counters.bcnt;
+ pcnt = iter->counters.pcnt;
+ } while (read_seqretry(lock, start));
+
+ ADD_COUNTER(counters[i], bcnt, pcnt);
++i; /* macro does multi eval of i */
}
- xt_info_wrunlock(cpu);
- local_bh_enable();
}
- put_cpu();
}
static struct xt_counters *alloc_counters(const struct xt_table *table)
@@ -932,7 +915,7 @@ static struct xt_counters *alloc_counters(const struct xt_table *table)
(other than comefrom, which userspace doesn't care
about). */
countersize = sizeof(struct xt_counters) * private->number;
- counters = vmalloc(countersize);
+ counters = vzalloc(countersize);
if (counters == NULL)
return ERR_PTR(-ENOMEM);
@@ -1203,7 +1186,7 @@ __do_replace(struct net *net, const char *name, unsigned int valid_hooks,
struct ipt_entry *iter;
ret = 0;
- counters = vmalloc(num_counters * sizeof(struct xt_counters));
+ counters = vzalloc(num_counters * sizeof(struct xt_counters));
if (!counters) {
ret = -ENOMEM;
goto out;
diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c
index 4555823..7d227c6 100644
--- a/net/ipv6/netfilter/ip6_tables.c
+++ b/net/ipv6/netfilter/ip6_tables.c
@@ -897,42 +897,25 @@ get_counters(const struct xt_table_info *t,
struct ip6t_entry *iter;
unsigned int cpu;
unsigned int i;
- unsigned int curcpu = get_cpu();
-
- /* Instead of clearing (by a previous call to memset())
- * the counters and using adds, we set the counters
- * with data used by 'current' CPU
- *
- * Bottom half has to be disabled to prevent deadlock
- * if new softirq were to run and call ipt_do_table
- */
- local_bh_disable();
- i = 0;
- xt_entry_foreach(iter, t->entries[curcpu], t->size) {
- SET_COUNTER(counters[i], iter->counters.bcnt,
- iter->counters.pcnt);
- ++i;
- }
- local_bh_enable();
- /* Processing counters from other cpus, we can let bottom half enabled,
- * (preemption is disabled)
- */
for_each_possible_cpu(cpu) {
- if (cpu == curcpu)
- continue;
+ seqlock_t *lock = &per_cpu(xt_info_locks, cpu).lock;
+
i = 0;
- local_bh_disable();
- xt_info_wrlock(cpu);
xt_entry_foreach(iter, t->entries[cpu], t->size) {
- ADD_COUNTER(counters[i], iter->counters.bcnt,
- iter->counters.pcnt);
+ u64 bcnt, pcnt;
+ unsigned int start;
+
+ do {
+ start = read_seqbegin(lock);
+ bcnt = iter->counters.bcnt;
+ pcnt = iter->counters.pcnt;
+ } while (read_seqretry(lock, start));
+
+ ADD_COUNTER(counters[i], bcnt, pcnt);
++i;
}
- xt_info_wrunlock(cpu);
- local_bh_enable();
}
- put_cpu();
}
static struct xt_counters *alloc_counters(const struct xt_table *table)
@@ -945,7 +928,7 @@ static struct xt_counters *alloc_counters(const struct xt_table *table)
(other than comefrom, which userspace doesn't care
about). */
countersize = sizeof(struct xt_counters) * private->number;
- counters = vmalloc(countersize);
+ counters = vzalloc(countersize);
if (counters == NULL)
return ERR_PTR(-ENOMEM);
@@ -1216,7 +1199,7 @@ __do_replace(struct net *net, const char *name, unsigned int valid_hooks,
struct ip6t_entry *iter;
ret = 0;
- counters = vmalloc(num_counters * sizeof(struct xt_counters));
+ counters = vzalloc(num_counters * sizeof(struct xt_counters));
if (!counters) {
ret = -ENOMEM;
goto out;
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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 related
* Re: [PATCH V7 1/8] ntp: add ADJ_SETOFFSET mode bit
From: Thomas Gleixner @ 2010-12-16 17:48 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
John Stultz, Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti
In-Reply-To: <880d82bb8120f73973db27e0c48e949014b1a106.1292512461.git.richard.cochran-3mrvs1K0uXizZXS1Dc/lvw@public.gmane.org>
On Thu, 16 Dec 2010, Richard Cochran wrote:
> + if (txc->modes & ADJ_SETOFFSET) {
> + /* Validate the delta value. */
> + if (txc->time.tv_sec && txc->time.tv_usec < 0)
> + return -EINVAL;
> +
> + if (txc->modes & ADJ_NANO) {
> + struct timespec tmp;
> + tmp.tv_sec = txc->time.tv_sec;
> + tmp.tv_nsec = txc->time.tv_usec;
> + delta = timespec_to_ktime(tmp);
> + } else
> + delta = timeval_to_ktime(txc->time);
> +
> + /* Adding the delta should be an "atomic" operation. */
> + local_irq_disable();
I really do not like that conditional irq_disable(), especially as we
disable them further down again and we only safe the getnstimeofday()
call in the non ADJSETOFFSET code path.
So we really better do that unconditionally before getnstimeofday()
with an appropriate comment and change the write_seqlock_irq() to
write_seqlock().
> + }
> +
> getnstimeofday(&ts);
>
> + if (txc->modes & ADJ_SETOFFSET) {
> + kt = timespec_to_ktime(ts);
> + kt = ktime_add(kt, delta);
> + ts = ktime_to_timespec(kt);
> + do_settimeofday(&ts);
> + local_irq_enable();
> + }
> +
> write_seqlock_irq(&xtime_lock);
Thanks,
tglx
>
^ permalink raw reply
* Re: pktgen IP address stepping
From: David Miller @ 2010-12-16 17:44 UTC (permalink / raw)
To: kristian; +Cc: netdev
In-Reply-To: <20101216172800.GA8404@spritelink.se>
From: Kristian Larsson <kristian@spritelink.net>
Date: Thu, 16 Dec 2010 18:28:00 +0100
> Looking forward to any feedback and / or suggestions.
If you need a huge type for the step values in order to handle ipv6
addresses or similar, used a fixed sized type such as "u64" instead of
"unsigned long long".
^ permalink raw reply
* pktgen IP address stepping
From: Kristian Larsson @ 2010-12-16 17:28 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 3270 bytes --]
Hello David (and list)!
First of all, I'm hoping I'm sending this to the right person / list,
I've never submitted nor written a patch for the Linux kernel before,
so please bare with me.
This patch adds the ability to set the step rate at which the source
or destination IP address is increased when src_min / src_max or
dst_min / dst_max is used with pktgen.
Usage is simple, two new parameters:
src_step X
dst_step X
where X is a positive integer (or actually an unsigned long long).
This is useful for network testing when you want to send packets to
large parts of the Internet.
In addition to adding stepping support, I've changed the init value of
current source / destination address in the code to the max. The
current kernel sets it to the min value, but before the first packet
is sent out, the value is increased. By setting it to max, and we try
to increase it, it will wrap and thus actually start at the min value.
I find this more intuitive and to follow the principle of least
astonishement - I'd actually go as far as say the old behaviour is a
bug. Anyway, there are also some formatting changes and editorial
nitpicks. Of course, src / dst step has been added to the output of
the proc interface.
My tests involved performance measurements of routers, specifically in
the area of convergence times. Most larger routers implement their FIB
in a TCAM, SRAM or something similarly fast and deterministic. While
reads, ie lookups are often very fast, updates are often quite slow.
My testing show some platforms rewriting some 2000 prefixes per
seconds. So basically, what I wanted to test was just how routers
rewrite their FIB and so I needed to send a packet to every prefix they
have stored in FIB and receive it on one of two output interfaces - the
first if the reroute has not yet happened and on the second interface
if it has. Since I'm dealing with Internet core routers that means I
have a full BGP table (ie some 330k prefix as of late 2010) and I thus
want to send one packet, or 330k packets per second, to each and every
prefix. In addition, it would require to me to input a list of
prefixes to pktgen somehow as the prefixes certainly aren't evenly
spread out (ie, not evenly sized). Instead of implementing that, I
went for an approximation, sending a packet to every Nth address,
which in my case is 65535, or every /16. This gives a pretty good
approximate of the entire routing table, at least good enough for my
tests.
Tests will be posted on http://labs.spritelink.net for those
interested. It will probably be until the beginning of next year
before anything is posted since most of the testing is performed at my
employer, Tele2, and we need to wrap it all up first.
The changes included in this patch was developed during my own (and
not my employers) time and I give permission to place it under whatever
license needed for inclusion in the Linux kernel. pktgen.c appeared to
include some list of changes at the top so I added myself, if this is
too small a change or whatever, that can of course be removed.
Looking forward to any feedback and / or suggestions.
Kind regards,
Kristian.
--
Kristian Larsson KLL-RIPE
+46 704 264511 kll@spritelink.net
[-- Attachment #2: linux-pktgen-step.patch --]
[-- Type: text/x-diff, Size: 4299 bytes --]
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 2953b2a..391cecc 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -114,6 +114,9 @@
* Fixed src_mac command to set source mac of packet to value specified in
* command by Adit Ranadive <adit.262@gmail.com>
*
+ * Added support for increasing src / dst ip by values larger than one (1) when
+ * doing src or dst min/max by Kristian Larsson <kll@spritelink.net>
+ *
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -288,6 +291,10 @@ struct pktgen_dev {
char src_min[IP_NAME_SZ]; /* IP, ie 1.2.3.4 */
char src_max[IP_NAME_SZ]; /* IP, ie 1.2.3.4 */
+ unsigned long long dst_step;
+ unsigned long long src_step; /* Step up (ie increase) IP src / dst by this
+ much. 1 by default. */
+
struct in6_addr in6_saddr;
struct in6_addr in6_daddr;
struct in6_addr cur_in6_daddr;
@@ -572,11 +579,11 @@ static int pktgen_if_show(struct seq_file *seq, void *v)
} else {
seq_printf(seq,
- " dst_min: %s dst_max: %s\n",
- pkt_dev->dst_min, pkt_dev->dst_max);
+ " dst_min: %s dst_max: %s dst_step: %llu\n",
+ pkt_dev->dst_min, pkt_dev->dst_max, pkt_dev->dst_step);
seq_printf(seq,
- " src_min: %s src_max: %s\n",
- pkt_dev->src_min, pkt_dev->src_max);
+ " src_min: %s src_max: %s src_step: %llu\n",
+ pkt_dev->src_min, pkt_dev->src_max, pkt_dev->src_step);
}
seq_puts(seq, " src_mac: ");
@@ -1359,6 +1366,21 @@ static ssize_t pktgen_if_write(struct file *file,
sprintf(pg_result, "OK: dst6_max=%s", buf);
return count;
}
+ if (!strcmp(name, "dst_step")) {
+ len = num_arg(&user_buffer[i], 10, &value);
+ if (len < 0)
+ return len;
+
+ i += len;
+ if (!value)
+ return len;
+ pkt_dev->dst_step = value;
+ if (debug)
+ pr_info("pktgen: dst_step set to: %llu\n", pkt_dev->dst_step);
+
+ sprintf(pg_result, "OK: dst_step=%llu", pkt_dev->dst_step);
+ return count;
+ }
if (!strcmp(name, "src6")) {
len = strn_len(&user_buffer[i], sizeof(buf) - 1);
if (len < 0)
@@ -1424,6 +1446,21 @@ static ssize_t pktgen_if_write(struct file *file,
sprintf(pg_result, "OK: src_max=%s", pkt_dev->src_max);
return count;
}
+ if (!strcmp(name, "src_step")) {
+ len = num_arg(&user_buffer[i], 10, &value);
+ if (len < 0)
+ return len;
+
+ i += len;
+ if (!value)
+ return len;
+ pkt_dev->src_step = value;
+ if (debug)
+ pr_info("pktgen: src_step set to: %llu\n", pkt_dev->src_step);
+
+ sprintf(pg_result, "OK: src_step=%llu", pkt_dev->src_step);
+ return count;
+ }
if (!strcmp(name, "dst_mac")) {
char *v = valstr;
unsigned char old_dmac[ETH_ALEN];
@@ -2160,8 +2197,17 @@ static void pktgen_setup_inject(struct pktgen_dev *pkt_dev)
/* Initialize current values. */
pkt_dev->cur_dst_mac_offset = 0;
pkt_dev->cur_src_mac_offset = 0;
- pkt_dev->cur_saddr = pkt_dev->saddr_min;
- pkt_dev->cur_daddr = pkt_dev->daddr_min;
+
+ /*
+ * Setting init value of current src / dst addr to max value seems
+ * backwards, but it's not, it is increased for every run, including
+ * the first one and so setting it to min value means we never actually
+ * use the min value as it will be increased before we send the first
+ * packet. Max on the other hand means we wrap on first run and thus
+ * send first packet with min value.
+ */
+ pkt_dev->cur_saddr = pkt_dev->saddr_max;
+ pkt_dev->cur_daddr = pkt_dev->daddr_max;
pkt_dev->cur_udp_dst = pkt_dev->udp_dst_min;
pkt_dev->cur_udp_src = pkt_dev->udp_src_min;
pkt_dev->nflows = 0;
@@ -2414,7 +2460,7 @@ static void mod_cur_headers(struct pktgen_dev *pkt_dev)
t = random32() % (imx - imn) + imn;
else {
t = ntohl(pkt_dev->cur_saddr);
- t++;
+ t += pkt_dev->src_step;
if (t > imx)
t = imn;
@@ -2446,7 +2492,7 @@ static void mod_cur_headers(struct pktgen_dev *pkt_dev)
pkt_dev->cur_daddr = s;
} else {
t = ntohl(pkt_dev->cur_daddr);
- t++;
+ t += pkt_dev->dst_step;
if (t > imx) {
t = imn;
}
@@ -3752,6 +3798,8 @@ static int pktgen_add_device(struct pktgen_thread *t, const char *ifname)
pkt_dev->udp_src_max = 9;
pkt_dev->udp_dst_min = 9;
pkt_dev->udp_dst_max = 9;
+ pkt_dev->dst_step = 1;
+ pkt_dev->src_step = 1;
pkt_dev->vlan_p = 0;
pkt_dev->vlan_cfi = 0;
^ permalink raw reply related
* Re: [PATCH] ip: Few typo and grammar errors fixes for ip(8) manpage
From: Stephen Hemminger @ 2010-12-16 17:33 UTC (permalink / raw)
To: Petr Sabata; +Cc: netdev
In-Reply-To: <1292516694-9156-1-git-send-email-psabata@redhat.com>
On Thu, 16 Dec 2010 17:24:54 +0100
Petr Sabata <psabata@redhat.com> wrote:
> ---
> man/man8/ip.8 | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/man/man8/ip.8 b/man/man8/ip.8
> index 6c778d2..8d55fa9 100644
> --- a/man/man8/ip.8
> +++ b/man/man8/ip.8
> @@ -1289,7 +1289,7 @@ can also be
> .BI nud " NUD_STATE"
> the state of the neighbour entry.
> .B nud
> -is an abbreviation for 'Neigh bour Unreachability Detection'.
> +is an abbreviation for 'Neighbour Unreachability Detection'.
> The state can take one of the following values:
>
> .in +8
> @@ -1614,7 +1614,7 @@ peers are allowed to send to us.
> .BI rtt " TIME"
> the initial RTT ('Round Trip Time') estimate. If no suffix is
> specified the units are raw values passed directly to the
> -routing code to maintain compatability with previous releases.
> +routing code to maintain compatibility with previous releases.
> Otherwise if a suffix of s, sec or secs is used to specify
> seconds; ms, msec or msecs to specify milliseconds; us, usec
> or usecs to specify microseconds; ns, nsec or nsecs to specify
> @@ -2484,7 +2484,7 @@ contains one or more algorithms
> .I ALGO
> which depend on the type of algorithm set by
> .IR ALGO_TYPE "."
> -It can be used these algoritms
> +Valid algorithms are:
> .BR enc ", " auth " or " comp "."
>
> .SS ip xfrm policy add - add a new policy
Applied.
--
^ permalink raw reply
* Re: [PATCH v2 net-next-2.6] netfilter: ip_tables: dont block BH while reading counters
From: Stephen Hemminger @ 2010-12-16 17:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jesper Dangaard Brouer, Patrick McHardy, Arnaldo Carvalho de Melo,
Steven Rostedt, Alexander Duyck, netfilter-devel, netdev,
Peter P Waskiewicz Jr
In-Reply-To: <1292518436.2883.393.camel@edumazet-laptop>
On Thu, 16 Dec 2010 17:53:56 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> spinlock_t lock;
> + seqcount_t seq;
Since lock and seqcount_t are associated together, why isn't this a seqlock instead?
--
^ 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