* Re: [RFC PATCH 1/9] ipvs network name space aware
From: Daniel Lezcano @ 2010-10-18 8:59 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: lvs-devel, netdev, netfilter-devel, horms, ja, wensong
In-Reply-To: <201010081316.46690.hans.schillstrom@ericsson.com>
On 10/08/2010 01:16 PM, Hans Schillstrom wrote:
> This part contains the include files
> where include/net/netns/ip_vs.h is new and contains all moved vars.
>
> SUMMARY
>
> include/net/ip_vs.h | 136 ++++---
> include/net/net_namespace.h | 2 +
> include/net/netns/ip_vs.h | 112 +++++
>
> Signed-off-by:Hans Schillstrom<hans.schillstrom@ericsson.com>
> ---
>
>
[ ... ]
> #ifdef CONFIG_IP_VS_IPV6
> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> index bd10a79..b59cdc5 100644
> --- a/include/net/net_namespace.h
> +++ b/include/net/net_namespace.h
> @@ -15,6 +15,7 @@
> #include<net/netns/ipv4.h>
> #include<net/netns/ipv6.h>
> #include<net/netns/dccp.h>
> +#include<net/netns/ip_vs.h>
> #include<net/netns/x_tables.h>
> #if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
> #include<net/netns/conntrack.h>
> @@ -91,6 +92,7 @@ struct net {
> struct sk_buff_head wext_nlevents;
> #endif
> struct net_generic *gen;
> + struct netns_ipvs *ipvs;
> };
>
IMHO, it would be better to use the net_generic infra-structure instead
of adding a new field in the netns structure.
^ permalink raw reply
* [PATCH net-next 1/6] bnx2x: Optimized the branching in the bnx2x_rx_int()
From: Dmitry Kravkov @ 2010-10-18 9:02 UTC (permalink / raw)
To: davem, netdev; +Cc: eilong, vladz
From: Vladislav Zolotarov <vladz@broadcom.com>
Optimized the branching in the bnx2x_rx_int() based on the fact
that FP CQE will always have at least one of START or STOP flags set,
so if not both bits are set and START bit is not set,
then it's a STOP bit that is set.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_cmn.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_cmn.c b/drivers/net/bnx2x/bnx2x_cmn.c
index 97ef674..cb2a3d6 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/bnx2x/bnx2x_cmn.c
@@ -507,8 +507,11 @@ int bnx2x_rx_int(struct bnx2x_fastpath *fp, int budget)
len = le16_to_cpu(cqe->fast_path_cqe.pkt_len);
pad = cqe->fast_path_cqe.placement_offset;
- /* If CQE is marked both TPA_START and TPA_END
- it is a non-TPA CQE */
+ /* - If CQE is marked both TPA_START and TPA_END it is
+ * a non-TPA CQE.
+ * - FP CQE will always have either TPA_START or/and
+ * TPA_STOP flags set.
+ */
if ((!fp->disable_tpa) &&
(TPA_TYPE(cqe_fp_flags) !=
(TPA_TYPE_START | TPA_TYPE_END))) {
@@ -526,9 +529,7 @@ int bnx2x_rx_int(struct bnx2x_fastpath *fp, int budget)
bnx2x_set_skb_rxhash(bp, cqe, skb);
goto next_rx;
- }
-
- if (TPA_TYPE(cqe_fp_flags) == TPA_TYPE_END) {
+ } else { /* TPA_STOP */
DP(NETIF_MSG_RX_STATUS,
"calling tpa_stop on queue %d\n",
queue);
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 2/6] bnx2x: remove redundant commands during error handling
From: Dmitry Kravkov @ 2010-10-18 9:05 UTC (permalink / raw)
To: davem, netdev; +Cc: Eilon Greenstein, Vladislav Zolotarov
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_cmn.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_cmn.c b/drivers/net/bnx2x/bnx2x_cmn.c
index ddf90e1..3f0540c 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/bnx2x/bnx2x_cmn.c
@@ -1288,8 +1288,6 @@ int bnx2x_nic_load(struct bnx2x *bp, int load_mode)
if (rc) {
BNX2X_ERR("HW init failed, aborting\n");
bnx2x_fw_command(bp, DRV_MSG_CODE_LOAD_DONE, 0);
- bnx2x_fw_command(bp, DRV_MSG_CODE_UNLOAD_REQ_WOL_MCP, 0);
- bnx2x_fw_command(bp, DRV_MSG_CODE_UNLOAD_DONE, 0);
goto load_error2;
}
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 5/6] bnx2x: remove unnecessary FUNC_FLG_RSS flag and related
From: Dmitry Kravkov @ 2010-10-18 9:08 UTC (permalink / raw)
To: davem, netdev; +Cc: Eilon Greenstein, Vladislav Zolotarov
As suggested by: Joe Perches <joe@perches.com>
Although RSS is meaningless when there is a single HW queue we
still need it enabled in order to have HW Rx hash generated.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x.h | 13 ++-----
drivers/net/bnx2x/bnx2x_main.c | 70 +++++++++++++++++-----------------------
2 files changed, 34 insertions(+), 49 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index c49b643..556cad5 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -1180,15 +1180,10 @@ struct bnx2x {
TSTORM_ETH_FUNCTION_COMMON_CONFIG_RSS_IPV6_TCP_CAPABILITY
/* func init flags */
-#define FUNC_FLG_RSS 0x0001
-#define FUNC_FLG_STATS 0x0002
-/* removed FUNC_FLG_UNMATCHED 0x0004 */
-#define FUNC_FLG_TPA 0x0008
-#define FUNC_FLG_SPQ 0x0010
-#define FUNC_FLG_LEADING 0x0020 /* PF only */
-
-#define FUNC_CONFIG(flgs) ((flgs) & (FUNC_FLG_RSS | FUNC_FLG_TPA | \
- FUNC_FLG_LEADING))
+#define FUNC_FLG_STATS 0x0001
+#define FUNC_FLG_TPA 0x0002
+#define FUNC_FLG_SPQ 0x0004
+#define FUNC_FLG_LEADING 0x0008 /* PF only */
struct rxq_pause_params {
u16 bd_th_lo;
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index ead524b..012c093 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -2284,35 +2284,31 @@ void bnx2x_rxq_set_mac_filters(struct bnx2x *bp, u16 cl_id, u32 filters)
void bnx2x_func_init(struct bnx2x *bp, struct bnx2x_func_init_params *p)
{
- if (FUNC_CONFIG(p->func_flgs)) {
- struct tstorm_eth_function_common_config tcfg = {0};
-
- /* tpa */
- if (p->func_flgs & FUNC_FLG_TPA)
- tcfg.config_flags |=
- TSTORM_ETH_FUNCTION_COMMON_CONFIG_ENABLE_TPA;
-
- /* set rss flags */
- if (p->func_flgs & FUNC_FLG_RSS) {
- u16 rss_flgs = (p->rss->mode <<
- TSTORM_ETH_FUNCTION_COMMON_CONFIG_RSS_MODE_SHIFT);
-
- if (p->rss->cap & RSS_IPV4_CAP)
- rss_flgs |= RSS_IPV4_CAP_MASK;
- if (p->rss->cap & RSS_IPV4_TCP_CAP)
- rss_flgs |= RSS_IPV4_TCP_CAP_MASK;
- if (p->rss->cap & RSS_IPV6_CAP)
- rss_flgs |= RSS_IPV6_CAP_MASK;
- if (p->rss->cap & RSS_IPV6_TCP_CAP)
- rss_flgs |= RSS_IPV6_TCP_CAP_MASK;
-
- tcfg.config_flags |= rss_flgs;
- tcfg.rss_result_mask = p->rss->result_mask;
+ struct tstorm_eth_function_common_config tcfg = {0};
+ u16 rss_flgs;
- }
+ /* tpa */
+ if (p->func_flgs & FUNC_FLG_TPA)
+ tcfg.config_flags |=
+ TSTORM_ETH_FUNCTION_COMMON_CONFIG_ENABLE_TPA;
- storm_memset_func_cfg(bp, &tcfg, p->func_id);
- }
+ /* set rss flags */
+ rss_flgs = (p->rss->mode <<
+ TSTORM_ETH_FUNCTION_COMMON_CONFIG_RSS_MODE_SHIFT);
+
+ if (p->rss->cap & RSS_IPV4_CAP)
+ rss_flgs |= RSS_IPV4_CAP_MASK;
+ if (p->rss->cap & RSS_IPV4_TCP_CAP)
+ rss_flgs |= RSS_IPV4_TCP_CAP_MASK;
+ if (p->rss->cap & RSS_IPV6_CAP)
+ rss_flgs |= RSS_IPV6_CAP_MASK;
+ if (p->rss->cap & RSS_IPV6_TCP_CAP)
+ rss_flgs |= RSS_IPV6_TCP_CAP_MASK;
+
+ tcfg.config_flags |= rss_flgs;
+ tcfg.rss_result_mask = p->rss->result_mask;
+
+ storm_memset_func_cfg(bp, &tcfg, p->func_id);
/* Enable the function in the FW */
storm_memset_vf_to_pf(bp, p->func_id, p->pf_id);
@@ -2479,23 +2475,17 @@ void bnx2x_pf_init(struct bnx2x *bp)
else
flags |= FUNC_FLG_TPA;
+ /* function setup */
+
/**
* Although RSS is meaningless when there is a single HW queue we
* still need it enabled in order to have HW Rx hash generated.
- *
- * if (is_eth_multi(bp))
- * flags |= FUNC_FLG_RSS;
*/
- flags |= FUNC_FLG_RSS;
-
- /* function setup */
- if (flags & FUNC_FLG_RSS) {
- rss.cap = (RSS_IPV4_CAP | RSS_IPV4_TCP_CAP |
- RSS_IPV6_CAP | RSS_IPV6_TCP_CAP);
- rss.mode = bp->multi_mode;
- rss.result_mask = MULTI_MASK;
- func_init.rss = &rss;
- }
+ rss.cap = (RSS_IPV4_CAP | RSS_IPV4_TCP_CAP |
+ RSS_IPV6_CAP | RSS_IPV6_TCP_CAP);
+ rss.mode = bp->multi_mode;
+ rss.result_mask = MULTI_MASK;
+ func_init.rss = &rss;
func_init.func_flgs = flags;
func_init.pf_id = BP_FUNC(bp);
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 0/6] bnx2x: patch series
From: Dmitry Kravkov @ 2010-10-18 8:59 UTC (permalink / raw)
To: davem; +Cc: netdev, eilong, vladz
Hi Dave,
This is the respin of previous series with following changes:
1. removed patch with gso_size
2. removed FUNC_FLG_RSS flag and appropriate "if"s (as suggested by Joe Perches)
3. update version
Please, consider applying to net-next
Thanks
Dmitry
^ permalink raw reply
* [PATCH net-next 6/6] bnx2x: update version to 1.60.00-2
From: Dmitry Kravkov @ 2010-10-18 9:08 UTC (permalink / raw)
To: davem, netdev; +Cc: Eilon Greenstein, Vladislav Zolotarov
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 7d7af10..b387717 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -20,8 +20,8 @@
* (you will need to reboot afterwards) */
/* #define BNX2X_STOP_ON_ERROR */
-#define DRV_MODULE_VERSION "1.60.00-1"
-#define DRV_MODULE_RELDATE "2010/10/06"
+#define DRV_MODULE_VERSION "1.60.00-2"
+#define DRV_MODULE_RELDATE "2010/10/18"
#define BNX2X_BC_VER 0x040200
#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next 3/6] bnx2x: do not deal with power if no capability
From: Dmitry Kravkov @ 2010-10-18 9:10 UTC (permalink / raw)
To: davem, netdev; +Cc: Eilon Greenstein, Vladislav Zolotarov
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_cmn.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_cmn.c b/drivers/net/bnx2x/bnx2x_cmn.c
index 3f0540c..9a3208e 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/bnx2x/bnx2x_cmn.c
@@ -1520,6 +1520,12 @@ int bnx2x_set_power_state(struct bnx2x *bp, pci_power_t state)
{
u16 pmcsr;
+ /* If there is no power capability, silently succeed */
+ if (!bp->pm_cap) {
+ DP(NETIF_MSG_HW, "No power capability. Breaking.\n");
+ return 0;
+ }
+
pci_read_config_word(bp->pdev, bp->pm_cap + PCI_PM_CTRL, &pmcsr);
switch (state) {
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 4/6] bnx2x: Use correct FW constant for header padding
From: Dmitry Kravkov @ 2010-10-18 9:09 UTC (permalink / raw)
To: davem, netdev; +Cc: Eilon Greenstein, Vladislav Zolotarov
the value of the constant is the same, but it's clearer to use original
constant provided by HSI
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_cmn.c | 2 +-
drivers/net/bnx2x/bnx2x_cmn.h | 2 --
2 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_cmn.c b/drivers/net/bnx2x/bnx2x_cmn.c
index 9a3208e..29ed500 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/bnx2x/bnx2x_cmn.c
@@ -830,7 +830,7 @@ void bnx2x_init_rx_rings(struct bnx2x *bp)
int i, j;
bp->rx_buf_size = bp->dev->mtu + ETH_OVREHEAD + BNX2X_RX_ALIGN +
- BNX2X_FW_IP_HDR_ALIGN_PAD;
+ IP_HEADER_ALIGNMENT_PADDING;
DP(NETIF_MSG_IFUP,
"mtu %d rx_buf_size %d\n", bp->dev->mtu, bp->rx_buf_size);
diff --git a/drivers/net/bnx2x/bnx2x_cmn.h b/drivers/net/bnx2x/bnx2x_cmn.h
index 7f52cec..5bfe0ab 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.h
+++ b/drivers/net/bnx2x/bnx2x_cmn.h
@@ -1032,6 +1032,4 @@ static inline void storm_memset_cmng(struct bnx2x *bp,
void bnx2x_acquire_phy_lock(struct bnx2x *bp);
void bnx2x_release_phy_lock(struct bnx2x *bp);
-#define BNX2X_FW_IP_HDR_ALIGN_PAD 2 /* FW places hdr with this padding */
-
#endif /* BNX2X_CMN_H */
--
1.7.1
^ permalink raw reply related
* Re: [PATCH resend] netfilter: fix kconfig unmet dependency warning
From: Patrick McHardy @ 2010-10-18 9:14 UTC (permalink / raw)
To: Randy Dunlap; +Cc: netdev, davem, netfilter-devel
In-Reply-To: <20101016191103.ba9b2e7e.randy.dunlap@oracle.com>
Am 17.10.2010 04:11, schrieb Randy Dunlap:
> Fix netfilter kconfig unmet dependencies warning & spell out
> "compatible" while there.
>
> warning: (IP_NF_TARGET_TTL && NET && INET && NETFILTER && IP_NF_IPTABLES && NETFILTER_ADVANCED || IP6_NF_TARGET_HL && NET && INET && IPV6 && NETFILTER && IP6_NF_IPTABLES && NETFILTER_ADVANCED) selects NETFILTER_XT_TARGET_HL which has unmet direct dependencies ((IP_NF_MANGLE || IP6_NF_MANGLE) && NETFILTER_ADVANCED)
Applied, thanks.
^ permalink raw reply
* Re: [PATCH V2 0/7] can: mcp251x: fix and optimize driver
From: Marc Kleine-Budde @ 2010-10-18 9:19 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4CBB0851.9060601-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 510 bytes --]
On 10/17/2010 04:29 PM, Wolfgang Grandegger wrote:
> Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
tnx, I'm going to repost the series with you Ack and ask David to pull
it to net-next-2.6.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [RFC PATCH 1/9] ipvs network name space aware
From: Hans Schillstrom @ 2010-10-18 9:54 UTC (permalink / raw)
To: Daniel Lezcano
Cc: lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, horms@verge.net.au, ja@ssi.bg,
wensong@linux-vs.org
In-Reply-To: <4CBC0C6D.1080303@free.fr>
On Monday 18 October 2010 10:59:25 Daniel Lezcano wrote:
> On 10/08/2010 01:16 PM, Hans Schillstrom wrote:
> > This part contains the include files
> > where include/net/netns/ip_vs.h is new and contains all moved vars.
> >
> > SUMMARY
> >
> > include/net/ip_vs.h | 136 ++++---
> > include/net/net_namespace.h | 2 +
> > include/net/netns/ip_vs.h | 112 +++++
> >
> > Signed-off-by:Hans Schillstrom<hans.schillstrom@ericsson.com>
> > ---
> >
> >
>
> [ ... ]
>
> > #ifdef CONFIG_IP_VS_IPV6
> > diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> > index bd10a79..b59cdc5 100644
> > --- a/include/net/net_namespace.h
> > +++ b/include/net/net_namespace.h
> > @@ -15,6 +15,7 @@
> > #include<net/netns/ipv4.h>
> > #include<net/netns/ipv6.h>
> > #include<net/netns/dccp.h>
> > +#include<net/netns/ip_vs.h>
> > #include<net/netns/x_tables.h>
> > #if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
> > #include<net/netns/conntrack.h>
> > @@ -91,6 +92,7 @@ struct net {
> > struct sk_buff_head wext_nlevents;
> > #endif
> > struct net_generic *gen;
> > + struct netns_ipvs *ipvs;
> > };
> >
>
> IMHO, it would be better to use the net_generic infra-structure instead
> of adding a new field in the netns structure.
>
>
I realized that to, but the performance penalty is quite high with net_generic :-(
But on the other hand if you are going to backport it, (without recompiling the kernel)
you gonna need it!
My sugestion, take both with a configuration switch like:
(i.e. avoid the rcu locking)
--- net/ip_vs.h ---
...
extern int ip_vs_net_id; /* net id for ip_vs */
static inline struct netns_ipvs * net_ipvs(struct net* net, int id) {
#ifdef CONFIG_IP_VS_FAST_NETNS
return net->ipvs;
#else
return (struct netns_ipvs *)net_generic(net, id);
#endif
}
...
and where you need the netns_ipvs struct ptr,
[snip]
struct ip_vs_conn *ip_vs_conn_in_get(struct net *net, ....
{
struct netns_ipvs *ipvs = net_ipvs(net, ip_vs_net_id);
...
--
Regards
Hans Schillstrom <hans.schillstrom@ericsson.com>
^ permalink raw reply
* Re: [PATCH net-next 3/5] tipc: Optimizations to bearer enabling logic
From: Neil Horman @ 2010-10-18 10:50 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: davem, netdev, allan.stephens
In-Reply-To: <4CB8C824.7090800@windriver.com>
On Fri, Oct 15, 2010 at 05:31:16PM -0400, Paul Gortmaker wrote:
> On 10-10-15 07:00 AM, Neil Horman wrote:
>
> [...]
>
> > This definately looks more concise, but I don't see why its necessecary to drop
> > the tipc_net_lock around the call to enable_bearer. The only caler of
> > tipc_register_media sets the enable_bearer pointer to the enable_bearer
> > function, and I' don't see any path through that function which would
> > potentially retake that lock. In fact it seems dropping it might be dangerous,
> > if other paths (like from cfg_named_msg_event), tried to enable a bearer in
> > parallel with a user space directive from the netlink socket). With out the
> > protection of tipc_net_lock, you could use the same eth_bearer twice, and
> > corrupt that array.
>
> I think it would be protected by config_lock. but in the end if it is
> just an academic optimization that really isn't in a hot code path
> anyway, and if it just adds more confusion than real world value, then
> I'm fine with just dropping this on the floor (and deleting the extra
> memset in a cleanup patch) -- it won't be the 1st time doing this with
> these carry forward patches, and I'm sure it won't be the last.
>
Copy that.
>
^ permalink raw reply
* [MeeGo-Dev] can: How to set bitrate
From: Masayuki Ohtake @ 2010-10-18 10:56 UTC (permalink / raw)
To: Wolfgang Grandegger, David S. Miller, Wolfram Sang,
Christian Pellegrin, "Barry Song" <2
Cc: andrew.chih.howe.khor, Wang, Qi, Foster, Margie, Wang, Yong Y,
Ewe, Kok Howg, Tomoya MORINAGA, Intel OTC
I want to test our Socket CAN driver(for Topcliff) on Meego1.0.
For setting bitrate, I tried to install "iproute2". But the build failed.
================================================
[root@localhost iproute2-2.6.33]# make
sh configure
TC schedulers
ATM no
IPT using iptables
make[1]: Entering directory `/root/iproute2-2.6.33/lib'
<omission>
ude -o arpd arpd.c ../lib/libnetlink.a ../lib/libutil.a -ldb -lpthread
arpd.c:19:20: error: db_185.h: No such file or directory
arpd.c:42: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
arpd.c: In function 'do_one_request':
arpd.c:304: error: 'DBT' undeclared (first use in this function)
arpd.c:304: error: (Each undeclared identifier is reported only once
arpd.c:304: error: for each function it appears in.)
arpd.c:304: error: expected ';' before 'dbkey'
arpd.c:308: error: 'dbase' undeclared (first use in this function)
arpd.c:338: error: 'dbkey' undeclared (first use in this function)
arpd.c:341: error: 'dbdat' undeclared (first use in this function)
arpd.c: In function 'get_arp_pkt':
arpd.c:485: error: 'DBT' undeclared (first use in this function)
arpd.c:485: error: expected ';' before 'dbkey'
arpd.c:517: error: 'dbkey' undeclared (first use in this function)
arpd.c:520: error: 'dbase' undeclared (first use in this function)
arpd.c:520: error: 'dbdat' undeclared (first use in this function)
arpd.c: In function 'main':
arpd.c:670: error: 'dbase' undeclared (first use in this function)
arpd.c:670: warning: implicit declaration of function 'dbopen'
arpd.c:670: error: 'DB_HASH' undeclared (first use in this function)
arpd.c:680: error: 'DBT' undeclared (first use in this function)
arpd.c:680: error: expected ';' before 'dbkey'
arpd.c:682: error: 'dbkey' undeclared (first use in this function)
arpd.c:712: error: 'dbdat' undeclared (first use in this function)
arpd.c:728: error: expected ';' before 'dbkey'
arpd.c:730: error: 'R_NEXT' undeclared (first use in this function)
make[1]: *** [arpd] Error 1
make[1]: Leaving directory `/root/iproute2/misc'
make: *** [all] Error 2
[root@localhost iproute2]#
================================================
Do you know how to set bitrate on Meego?
Thanks, Ohtake(OKISemi)
^ permalink raw reply
* Re: [MeeGo-Dev] can: How to set bitrate
From: Wolfgang Grandegger @ 2010-10-18 11:05 UTC (permalink / raw)
To: Masayuki Ohtake
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w, Samuel Ortiz,
Foster, Margie, ML netdev, ML linux-kernel,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Wang, Yong Y,
Ewe, Kok Howg, Intel OTC, Tomoya MORINAGA, David S. Miller,
Christian Pellegrin, Wang, Qi
In-Reply-To: <000b01cb6eb3$1afcfd60$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org>
On 10/18/2010 12:56 PM, Masayuki Ohtake wrote:
> I want to test our Socket CAN driver(for Topcliff) on Meego1.0.
>
> For setting bitrate, I tried to install "iproute2". But the build failed.
>
> ================================================
> [root@localhost iproute2-2.6.33]# make
> sh configure
> TC schedulers
> ATM no
> IPT using iptables
> make[1]: Entering directory `/root/iproute2-2.6.33/lib'
>
> <omission>
>
> ude -o arpd arpd.c ../lib/libnetlink.a ../lib/libutil.a -ldb -lpthread
> arpd.c:19:20: error: db_185.h: No such file or directory
> arpd.c:42: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
> arpd.c: In function 'do_one_request':
> arpd.c:304: error: 'DBT' undeclared (first use in this function)
> arpd.c:304: error: (Each undeclared identifier is reported only once
> arpd.c:304: error: for each function it appears in.)
> arpd.c:304: error: expected ';' before 'dbkey'
> arpd.c:308: error: 'dbase' undeclared (first use in this function)
> arpd.c:338: error: 'dbkey' undeclared (first use in this function)
> arpd.c:341: error: 'dbdat' undeclared (first use in this function)
> arpd.c: In function 'get_arp_pkt':
> arpd.c:485: error: 'DBT' undeclared (first use in this function)
> arpd.c:485: error: expected ';' before 'dbkey'
> arpd.c:517: error: 'dbkey' undeclared (first use in this function)
> arpd.c:520: error: 'dbase' undeclared (first use in this function)
> arpd.c:520: error: 'dbdat' undeclared (first use in this function)
> arpd.c: In function 'main':
> arpd.c:670: error: 'dbase' undeclared (first use in this function)
> arpd.c:670: warning: implicit declaration of function 'dbopen'
> arpd.c:670: error: 'DB_HASH' undeclared (first use in this function)
> arpd.c:680: error: 'DBT' undeclared (first use in this function)
> arpd.c:680: error: expected ';' before 'dbkey'
> arpd.c:682: error: 'dbkey' undeclared (first use in this function)
> arpd.c:712: error: 'dbdat' undeclared (first use in this function)
> arpd.c:728: error: expected ';' before 'dbkey'
> arpd.c:730: error: 'R_NEXT' undeclared (first use in this function)
> make[1]: *** [arpd] Error 1
> make[1]: Leaving directory `/root/iproute2/misc'
> make: *** [all] Error 2
> [root@localhost iproute2]#
> ================================================
On my system I get:
~$ rpm -qf /usr/include/db_185.h
db4-devel-4.7.25-13.fc12.i686
Which means you need db4 devel to fully build iproute2.
> Do you know how to set bitrate on Meego?
ip from iproute2 is the right tool.
Wolfgang.
^ permalink raw reply
* Requesting For Your Partnersip!!!
From: Wen Lee @ 2010-10-18 11:06 UTC (permalink / raw)
--
My name is Mr. Wen Lee an account officer with the Bank of Taipei, I am requesting for your partnership in re-profiling funds and you will be paid 30% for your management fees; Contact me for details.
^ permalink raw reply
* Re: [RFC PATCH 1/9] ipvs network name space aware
From: Daniel Lezcano @ 2010-10-18 11:37 UTC (permalink / raw)
To: Hans Schillstrom
Cc: lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, horms@verge.net.au, ja@ssi.bg,
wensong@linux-vs.org
In-Reply-To: <201010181154.35792.hans.schillstrom@ericsson.com>
On 10/18/2010 11:54 AM, Hans Schillstrom wrote:
> On Monday 18 October 2010 10:59:25 Daniel Lezcano wrote:
>
>> On 10/08/2010 01:16 PM, Hans Schillstrom wrote:
>>
>>> This part contains the include files
>>> where include/net/netns/ip_vs.h is new and contains all moved vars.
>>>
>>> SUMMARY
>>>
>>> include/net/ip_vs.h | 136 ++++---
>>> include/net/net_namespace.h | 2 +
>>> include/net/netns/ip_vs.h | 112 +++++
>>>
>>> Signed-off-by:Hans Schillstrom<hans.schillstrom@ericsson.com>
>>> ---
>>>
>>>
>>>
>> [ ... ]
>>
>>
>>> #ifdef CONFIG_IP_VS_IPV6
>>> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
>>> index bd10a79..b59cdc5 100644
>>> --- a/include/net/net_namespace.h
>>> +++ b/include/net/net_namespace.h
>>> @@ -15,6 +15,7 @@
>>> #include<net/netns/ipv4.h>
>>> #include<net/netns/ipv6.h>
>>> #include<net/netns/dccp.h>
>>> +#include<net/netns/ip_vs.h>
>>> #include<net/netns/x_tables.h>
>>> #if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
>>> #include<net/netns/conntrack.h>
>>> @@ -91,6 +92,7 @@ struct net {
>>> struct sk_buff_head wext_nlevents;
>>> #endif
>>> struct net_generic *gen;
>>> + struct netns_ipvs *ipvs;
>>> };
>>>
>>>
>> IMHO, it would be better to use the net_generic infra-structure instead
>> of adding a new field in the netns structure.
>>
>>
>>
> I realized that to, but the performance penalty is quite high with net_generic :-(
> But on the other hand if you are going to backport it, (without recompiling the kernel)
> you gonna need it!
>
Hmm, yes. We don't want to have the init_net_ns performances to be impacted.
You use here a pointer which will be dereferenced like the net_generic,
I don't think there will be
a big difference between using net_generic and using a pointer in the
net namespace structure.
The difference is the id usage, but this one is based on the idr which
is quite fast.
We should experiment a bit here to compare both solutions.
IMHO, we can (1) create a non-pointer netns_ipvs field in the net
namespace structure or (2) use a pointer [with net_generic].
(1) is the faster but with the drawback of having a bigger memory
footprint even if the ipvs module is not loaded.
In this case we have to take care of what we store in the netns_ipvs
structure, that is reduce the per namespace table and so. At the first
glance, I think we can reduce this to the sysctls and a very few data,
for example using global tables tagged with the namespace and we don't
break the cacheline alignment optimization.
(2) is slower but as the memory is allocated and freed when the module
is loaded/unloaded. What I don't like with this approach is we add some
overhead even if the netns is not compiled in the kernel.
> My sugestion, take both with a configuration switch like:
> (i.e. avoid the rcu locking)
>
> --- net/ip_vs.h ---
> ...
> extern int ip_vs_net_id; /* net id for ip_vs */
>
>
> static inline struct netns_ipvs * net_ipvs(struct net* net, int id) {
> #ifdef CONFIG_IP_VS_FAST_NETNS
> return net->ipvs;
> #else
> return (struct netns_ipvs *)net_generic(net, id);
> #endif
> }
> ...
>
> and where you need the netns_ipvs struct ptr,
> [snip]
> struct ip_vs_conn *ip_vs_conn_in_get(struct net *net, ....
> {
> struct netns_ipvs *ipvs = net_ipvs(net, ip_vs_net_id);
> ...
>
It is a nice way to wrap both solutions but at this point I don't think
it is worth to add a 3rd option to compile ipvs.
^ permalink raw reply
* [PATCH] qlcnic: update ethtool stats
From: Amit Kumar Salecha @ 2010-10-18 11:47 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty
Added statistics for Nic Partition supported adapter.
These statistics are maintined in device.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic_ethtool.c | 73 +++++++++++++++++++++++++++++++++-
1 files changed, 70 insertions(+), 3 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic_ethtool.c b/drivers/net/qlcnic/qlcnic_ethtool.c
index 2568aa6..25e93a5 100644
--- a/drivers/net/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/qlcnic/qlcnic_ethtool.c
@@ -78,7 +78,25 @@ static const struct qlcnic_stats qlcnic_gstrings_stats[] = {
};
+static const char qlcnic_device_gstrings_stats[][ETH_GSTRING_LEN] = {
+ "rx unicast frames",
+ "rx multicast frames",
+ "rx broadcast frames",
+ "rx dropped frames",
+ "rx errors",
+ "rx local frames",
+ "rx numbytes",
+ "tx unicast frames",
+ "tx multicast frames",
+ "tx broadcast frames",
+ "tx dropped frames",
+ "tx errors",
+ "tx local frames",
+ "tx numbytes",
+};
+
#define QLCNIC_STATS_LEN ARRAY_SIZE(qlcnic_gstrings_stats)
+#define QLCNIC_DEVICE_STATS_LEN ARRAY_SIZE(qlcnic_device_gstrings_stats)
static const char qlcnic_gstrings_test[][ETH_GSTRING_LEN] = {
"Register_Test_on_offline",
@@ -625,10 +643,13 @@ static int qlcnic_reg_test(struct net_device *dev)
static int qlcnic_get_sset_count(struct net_device *dev, int sset)
{
+ struct qlcnic_adapter *adapter = netdev_priv(dev);
switch (sset) {
case ETH_SS_TEST:
return QLCNIC_TEST_LEN;
case ETH_SS_STATS:
+ if (adapter->flags & QLCNIC_ESWITCH_ENABLED)
+ return QLCNIC_STATS_LEN + QLCNIC_DEVICE_STATS_LEN;
return QLCNIC_STATS_LEN;
default:
return -EOPNOTSUPP;
@@ -795,7 +816,8 @@ qlcnic_diag_test(struct net_device *dev, struct ethtool_test *eth_test,
static void
qlcnic_get_strings(struct net_device *dev, u32 stringset, u8 * data)
{
- int index;
+ struct qlcnic_adapter *adapter = netdev_priv(dev);
+ int index, i;
switch (stringset) {
case ETH_SS_TEST:
@@ -808,16 +830,43 @@ qlcnic_get_strings(struct net_device *dev, u32 stringset, u8 * data)
qlcnic_gstrings_stats[index].stat_string,
ETH_GSTRING_LEN);
}
- break;
+ if (!(adapter->flags & QLCNIC_ESWITCH_ENABLED))
+ return;
+ for (i = 0; i < QLCNIC_DEVICE_STATS_LEN; index++, i++) {
+ memcpy(data + index * ETH_GSTRING_LEN,
+ qlcnic_device_gstrings_stats[i],
+ ETH_GSTRING_LEN);
+ }
}
}
+#define QLCNIC_FILL_ESWITCH_STATS(VAL1) \
+ (((VAL1) == QLCNIC_ESW_STATS_NOT_AVAIL) ? 0 : VAL1)
+
+static void
+qlcnic_fill_device_stats(int *index, u64 *data,
+ struct __qlcnic_esw_statistics *stats)
+{
+ int ind = *index;
+
+ data[ind++] = QLCNIC_FILL_ESWITCH_STATS(stats->unicast_frames);
+ data[ind++] = QLCNIC_FILL_ESWITCH_STATS(stats->multicast_frames);
+ data[ind++] = QLCNIC_FILL_ESWITCH_STATS(stats->broadcast_frames);
+ data[ind++] = QLCNIC_FILL_ESWITCH_STATS(stats->dropped_frames);
+ data[ind++] = QLCNIC_FILL_ESWITCH_STATS(stats->errors);
+ data[ind++] = QLCNIC_FILL_ESWITCH_STATS(stats->local_frames);
+ data[ind++] = QLCNIC_FILL_ESWITCH_STATS(stats->numbytes);
+
+ *index = ind;
+}
+
static void
qlcnic_get_ethtool_stats(struct net_device *dev,
struct ethtool_stats *stats, u64 * data)
{
struct qlcnic_adapter *adapter = netdev_priv(dev);
- int index;
+ struct qlcnic_esw_statistics port_stats;
+ int index, ret;
for (index = 0; index < QLCNIC_STATS_LEN; index++) {
char *p =
@@ -827,6 +876,24 @@ qlcnic_get_ethtool_stats(struct net_device *dev,
(qlcnic_gstrings_stats[index].sizeof_stat ==
sizeof(u64)) ? *(u64 *)p:(*(u32 *)p);
}
+
+ if (!(adapter->flags & QLCNIC_ESWITCH_ENABLED))
+ return;
+
+ memset(&port_stats, 0, sizeof(struct qlcnic_esw_statistics));
+ ret = qlcnic_get_port_stats(adapter, adapter->ahw.pci_func,
+ QLCNIC_QUERY_RX_COUNTER, &port_stats.rx);
+ if (ret)
+ return;
+
+ qlcnic_fill_device_stats(&index, data, &port_stats.rx);
+
+ ret = qlcnic_get_port_stats(adapter, adapter->ahw.pci_func,
+ QLCNIC_QUERY_TX_COUNTER, &port_stats.tx);
+ if (ret)
+ return;
+
+ qlcnic_fill_device_stats(&index, data, &port_stats.tx);
}
static int qlcnic_set_tx_csum(struct net_device *dev, u32 data)
--
1.6.0.2
^ permalink raw reply related
* __bad_udelay in network driver breaks build
From: Andi Kleen @ 2010-10-18 11:52 UTC (permalink / raw)
To: netdev
Current Linus master x86-64 allyesconfig fails with
drivers/built-in.o: In function `tms380tr_chipset_init':
tms380tr.c:(.text+0x10f02de): undefined reference to `__bad_udelay'
tms380tr.c:(.text+0x10f03ab): undefined reference to `__bad_udelay'
tms380tr.c:(.text+0x10f0400): undefined reference to `__bad_udelay'
tms380tr.c:(.text+0x10f07b2): undefined reference to `__bad_udelay'
tms380tr.c:(.text+0x10f08ed): undefined reference to `__bad_udelay'
make[2]: *** [.tmp_vmlinux1] Error 1
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [RFC PATCH 0/9] ipvs network name space (netns) aware
From: Hans Schillstrom @ 2010-10-18 11:55 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, ja@ssi.bg, wensong@linux-vs.org,
daniel.lezcano@free.fr
In-Reply-To: <20101017064731.GA8152@verge.net.au>
On Sunday 17 October 2010 08:47:31 Simon Horman wrote:
> On Fri, Oct 08, 2010 at 01:16:36PM +0200, Hans Schillstrom wrote:
> > This patch series adds network name space (netns) support to the LVS.
> >
> > REVISION
> >
> > This is version 1
> >
> > OVERVIEW
> >
> > The patch doesn't remove or add any functionality except for netns.
> > For users that don't use network name space (netns) this patch is
> > completely transparent.
> >
> > No it's possible to run LVS in a Linux container (see lxc-tools)
> > i.e. a light weight virtualization. For example it's possible to run
> > one or several lvs on a real server in their own network name spaces.
> > >From the LVS point of view it looks like it runs on it's own machine.
> >
> > IMPLEMENTATION
> > Basic requirements for netns awareness
> > - Global variables has to be moved to dyn. allocated memory.
> >
> > Most global variables now resides in a struct ipvs { } in netns/ip_vs.h.
> > What is moved and what is not ?
> >
> > Some cache aligned locks are still in global, module init params and some debug_level.
> >
> > Algorithm files they are untouched.
> >
> > QUESTIONS
> > Drop rate in ip_vs_ctl per netns or grand total ?
This is a tricky one (I think),
if the interface is shared with root name-space and/or other name-spaces
- use grand total
if it's an "own interface"
- drop rate can/should be in netns...
>
> My gut-feeling is that per netns makes more sense.
>
> > Should more lock variables be moved (or less) ?
>
> I'm unsure what you are asking here but I will make a general statement
> about locking in IPVS: it needs work.
Some locks still resides as global variables, and others in netns_ipvs struct.
Since you have a lot of experience with IPVS locks,
you might have ideas what to move and what to not move.
>
> >
> > PATCH SET
> > This patch set is based upon net-next-2.6 (2.6.36-rc3) from 4 oct 2010
> > and [patch v4] ipvs: IPv6 tunnel mode
> >
> > Note: ip_vs_xmit.c will not work without "[patch v4] ipvs: IPv6 tunnel mode"
>
> Unfortunately the patches don't apply with the persistence engine
> patches which were recently merged into nf-next-2.6 (although
> "[patch v4.1 ]ipvs: IPv6 tunnel mode" is still unmerged).
>
I do have a patch based on the nf-next without the SIP/PE patch
> I'm happy to work with you to make the required changes there.
I would appreciate that.
>
> (I realise those patches weren't merged when you made your post.
> But regardless, either your or me will need to update the patches).
>
> Another issue is that your patches seem to be split in a way
> where the build breaks along the way. E.g. after applying
> patch 1, the build breaks. Could you please split things up
> in a manner such that this doesn't happen. The reason being
> that it breaks bisection.
>
Hmm, Daniel also pointed at this,
The Patch is quite large, and will become even larger with pe and sip.
My Idea was to review the patch in pieces and put it together in one or two large patches when submitting it.
I don't know that might be a stupid ?
It's hard to break it up, making the code reentrant causes changes every where.
Daniel L, had another approach break it into many many tiny patches.
> Lastly, could you provide a unique subject for each patch.
> I know its a bit tedious, but it does make a difference when
> browsing the changelog.
>
Yepp, no problem
> --
> To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards
Hans Schillstrom <hans.schillstrom@ericsson.com>
^ permalink raw reply
* [PATCH NEXT 1/2] netxen: fix race in tx stop queue
From: Amit Kumar Salecha @ 2010-10-18 12:03 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Rajesh Borundia
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
There is race between netif_stop_queue and netif_stopped_queue
check.So check once again if buffers are available to avoid race.
With above logic we can also get rid of tx lock in process_cmd_ring.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic.h | 5 ++++-
drivers/net/netxen/netxen_nic_hw.c | 10 ++++++++--
drivers/net/netxen/netxen_nic_init.c | 10 +++-------
drivers/net/netxen/netxen_nic_main.c | 15 +++++++--------
4 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 6dca357..92f89af 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -175,7 +175,10 @@
#define MAX_NUM_CARDS 4
#define MAX_BUFFERS_PER_CMD 32
-#define TX_STOP_THRESH ((MAX_SKB_FRAGS >> 2) + 4)
+#define MAX_TSO_HEADER_DESC 2
+#define MGMT_CMD_DESC_RESV 4
+#define TX_STOP_THRESH ((MAX_SKB_FRAGS >> 2) + MAX_TSO_HEADER_DESC \
+ + MGMT_CMD_DESC_RESV)
#define NX_MAX_TX_TIMEOUTS 2
/*
diff --git a/drivers/net/netxen/netxen_nic_hw.c b/drivers/net/netxen/netxen_nic_hw.c
index 29d7b93..10e2f13 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -598,8 +598,14 @@ netxen_send_cmd_descs(struct netxen_adapter *adapter,
if (nr_desc >= netxen_tx_avail(tx_ring)) {
netif_tx_stop_queue(tx_ring->txq);
- __netif_tx_unlock_bh(tx_ring->txq);
- return -EBUSY;
+ smp_mb();
+ if (netxen_tx_avail(tx_ring) > nr_desc) {
+ if (netxen_tx_avail(tx_ring) > TX_STOP_THRESH)
+ netif_tx_wake_queue(tx_ring->txq);
+ } else {
+ __netif_tx_unlock_bh(tx_ring->txq);
+ return -EBUSY;
+ }
}
do {
diff --git a/drivers/net/netxen/netxen_nic_init.c b/drivers/net/netxen/netxen_nic_init.c
index a2d805a..95fe552 100644
--- a/drivers/net/netxen/netxen_nic_init.c
+++ b/drivers/net/netxen/netxen_nic_init.c
@@ -1763,14 +1763,10 @@ int netxen_process_cmd_ring(struct netxen_adapter *adapter)
smp_mb();
- if (netif_queue_stopped(netdev) && netif_carrier_ok(netdev)) {
- __netif_tx_lock(tx_ring->txq, smp_processor_id());
- if (netxen_tx_avail(tx_ring) > TX_STOP_THRESH) {
+ if (netif_queue_stopped(netdev) && netif_carrier_ok(netdev))
+ if (netxen_tx_avail(tx_ring) > TX_STOP_THRESH)
netif_wake_queue(netdev);
- adapter->tx_timeo_cnt = 0;
- }
- __netif_tx_unlock(tx_ring->txq);
- }
+ adapter->tx_timeo_cnt = 0;
}
/*
* If everything is freed up to consumer then check if the ring is full
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 2c6ceeb..83ee554 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -125,11 +125,6 @@ netxen_nic_update_cmd_producer(struct netxen_adapter *adapter,
struct nx_host_tx_ring *tx_ring)
{
NXWRIO(adapter, tx_ring->crb_cmd_producer, tx_ring->producer);
-
- if (netxen_tx_avail(tx_ring) <= TX_STOP_THRESH) {
- netif_stop_queue(adapter->netdev);
- smp_mb();
- }
}
static uint32_t crb_cmd_consumer[4] = {
@@ -1209,7 +1204,7 @@ netxen_setup_netdev(struct netxen_adapter *adapter,
adapter->max_mc_count = 16;
netdev->netdev_ops = &netxen_netdev_ops;
- netdev->watchdog_timeo = 2*HZ;
+ netdev->watchdog_timeo = 5*HZ;
netxen_nic_change_mtu(netdev, netdev->mtu);
@@ -1825,9 +1820,13 @@ netxen_nic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
/* 4 fragments per cmd des */
no_of_desc = (frag_count + 3) >> 2;
- if (unlikely(no_of_desc + 2 > netxen_tx_avail(tx_ring))) {
+ if (unlikely(netxen_tx_avail(tx_ring) <= TX_STOP_THRESH)) {
netif_stop_queue(netdev);
- return NETDEV_TX_BUSY;
+ smp_mb();
+ if (netxen_tx_avail(tx_ring) > TX_STOP_THRESH)
+ netif_start_queue(netdev);
+ else
+ return NETDEV_TX_BUSY;
}
producer = tx_ring->producer;
--
1.6.0.2
^ permalink raw reply related
* [PATCH NEXT 2/2] netxen: mask correctable error
From: Amit Kumar Salecha @ 2010-10-18 12:03 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1287403422-10431-1-git-send-email-amit.salecha@qlogic.com>
HW workaround:
Disable logging of correctable error for some NX3031 based adapter.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic_hw.c | 4 ++--
drivers/net/netxen/netxen_nic_main.c | 26 ++++++++++++++++++++++++++
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_hw.c b/drivers/net/netxen/netxen_nic_hw.c
index 10e2f13..4b4ac71 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -1822,14 +1822,14 @@ int netxen_nic_get_board_info(struct netxen_adapter *adapter)
if (netxen_rom_fast_read(adapter, offset, &board_type))
return -EIO;
- adapter->ahw.board_type = board_type;
-
if (board_type == NETXEN_BRDTYPE_P3_4_GB_MM) {
u32 gpio = NXRD32(adapter, NETXEN_ROMUSB_GLB_PAD_GPIO_I);
if ((gpio & 0x8000) == 0)
board_type = NETXEN_BRDTYPE_P3_10G_TP;
}
+ adapter->ahw.board_type = board_type;
+
switch (board_type) {
case NETXEN_BRDTYPE_P2_SB35_4G:
adapter->ahw.port_type = NETXEN_NIC_GBE;
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 83ee554..6f11169 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1249,6 +1249,28 @@ netxen_setup_netdev(struct netxen_adapter *adapter,
return 0;
}
+#ifdef CONFIG_PCIEAER
+static void netxen_mask_aer_correctable(struct netxen_adapter *adapter)
+{
+ struct pci_dev *pdev = adapter->pdev;
+ struct pci_dev *root = pdev->bus->self;
+ u32 aer_pos;
+
+ if (adapter->ahw.board_type != NETXEN_BRDTYPE_P3_4_GB_MM &&
+ adapter->ahw.board_type != NETXEN_BRDTYPE_P3_10G_TP)
+ return;
+
+ if (root->pcie_type != PCI_EXP_TYPE_ROOT_PORT)
+ return;
+
+ aer_pos = pci_find_ext_capability(root, PCI_EXT_CAP_ID_ERR);
+ if (!aer_pos)
+ return;
+
+ pci_write_config_dword(root, aer_pos + PCI_ERR_COR_MASK, 0xffff);
+}
+#endif
+
static int __devinit
netxen_nic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
@@ -1317,6 +1339,10 @@ netxen_nic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
goto err_out_iounmap;
}
+#ifdef CONFIG_PCIEAER
+ netxen_mask_aer_correctable(adapter);
+#endif
+
/* Mezz cards have PCI function 0,2,3 enabled */
switch (adapter->ahw.board_type) {
case NETXEN_BRDTYPE_P2_SB31_10G_IMEZ:
--
1.6.0.2
^ permalink raw reply related
* Re: [RFC PATCH 0/9] ipvs network name space (netns) aware
From: Daniel Lezcano @ 2010-10-18 12:16 UTC (permalink / raw)
To: Hans Schillstrom
Cc: Simon Horman, lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, ja@ssi.bg, wensong@linux-vs.org
In-Reply-To: <201010181355.59763.hans.schillstrom@ericsson.com>
On 10/18/2010 01:55 PM, Hans Schillstrom wrote:
> On Sunday 17 October 2010 08:47:31 Simon Horman wrote:
>
>> On Fri, Oct 08, 2010 at 01:16:36PM +0200, Hans Schillstrom wrote:
>>
>>> This patch series adds network name space (netns) support to the LVS.
>>>
>>> REVISION
>>>
>>> This is version 1
>>>
>>> OVERVIEW
>>>
>>> The patch doesn't remove or add any functionality except for netns.
>>> For users that don't use network name space (netns) this patch is
>>> completely transparent.
>>>
>>> No it's possible to run LVS in a Linux container (see lxc-tools)
>>> i.e. a light weight virtualization. For example it's possible to run
>>> one or several lvs on a real server in their own network name spaces.
>>> > From the LVS point of view it looks like it runs on it's own machine.
>>>
>>> IMPLEMENTATION
>>> Basic requirements for netns awareness
>>> - Global variables has to be moved to dyn. allocated memory.
>>>
>>> Most global variables now resides in a struct ipvs { } in netns/ip_vs.h.
>>> What is moved and what is not ?
>>>
>>> Some cache aligned locks are still in global, module init params and some debug_level.
>>>
>>> Algorithm files they are untouched.
>>>
>>> QUESTIONS
>>> Drop rate in ip_vs_ctl per netns or grand total ?
>>>
> This is a tricky one (I think),
> if the interface is shared with root name-space and/or other name-spaces
> - use grand total
> if it's an "own interface"
> - drop rate can/should be in netns...
>
>
>> My gut-feeling is that per netns makes more sense.
>>
>>
>>> Should more lock variables be moved (or less) ?
>>>
>> I'm unsure what you are asking here but I will make a general statement
>> about locking in IPVS: it needs work.
>>
> Some locks still resides as global variables, and others in netns_ipvs struct.
> Since you have a lot of experience with IPVS locks,
> you might have ideas what to move and what to not move.
>
>
>>
>>> PATCH SET
>>> This patch set is based upon net-next-2.6 (2.6.36-rc3) from 4 oct 2010
>>> and [patch v4] ipvs: IPv6 tunnel mode
>>>
>>> Note: ip_vs_xmit.c will not work without "[patch v4] ipvs: IPv6 tunnel mode"
>>>
>> Unfortunately the patches don't apply with the persistence engine
>> patches which were recently merged into nf-next-2.6 (although
>> "[patch v4.1 ]ipvs: IPv6 tunnel mode" is still unmerged).
>>
>>
> I do have a patch based on the nf-next without the SIP/PE patch
>
>
>> I'm happy to work with you to make the required changes there.
>>
> I would appreciate that.
>
>
>> (I realise those patches weren't merged when you made your post.
>> But regardless, either your or me will need to update the patches).
>>
>> Another issue is that your patches seem to be split in a way
>> where the build breaks along the way. E.g. after applying
>> patch 1, the build breaks. Could you please split things up
>> in a manner such that this doesn't happen. The reason being
>> that it breaks bisection.
>>
>>
> Hmm, Daniel also pointed at this,
> The Patch is quite large, and will become even larger with pe and sip.
> My Idea was to review the patch in pieces and put it together in one or two large patches when submitting it.
> I don't know that might be a stupid ?
> It's hard to break it up, making the code reentrant causes changes every where.
>
> Daniel L, had another approach break it into many many tiny patches.
>
These patches can be folded if the result is an acceptable patch size.
The more important is to not break the init_net. Introducing the
namespace concept step by step, from the bottom-up in the call stack is
good because we focus first on making the namespace available in the
code while keeping the init_net functional. The small patches help to
git bisect and spot the patch which lead to a regression. As the patches
are small, it is easy to quickly find the culprit and fix it, especially
for the people who are not author of these patches.
During this step of namespace introduction, we prevent to unshare the
network for ipvs, with a non-op when the namespace is not init_net.
When everything is ready and the init_net is running without problem, we
remove the non-op and consolidate the namespace part of ipvs.
This is how I am used to do, but that does not imply it is the best way
to do that :)
>> Lastly, could you provide a unique subject for each patch.
>> I know its a bit tedious, but it does make a difference when
>> browsing the changelog.
>>
>>
> Yepp, no problem
>
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe lvs-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
* Re: openvswitch/flow WAS ( Re: [rfc] Merging the Open vSwitch datapath
From: jamal @ 2010-10-18 12:16 UTC (permalink / raw)
To: Jesse Gross; +Cc: Ben Pfaff, netdev, ovs-team
In-Reply-To: <AANLkTin-zmQdMC_nRvgRr5KdWQvee5xga5sjOfRN2McN@mail.gmail.com>
On Sat, 2010-10-16 at 12:33 -0700, Jesse Gross wrote:
> On Sat, Oct 16, 2010 at 4:35 AM, jamal <hadi@cyberus.ca> wrote:
> Yes, Open vSwitch supports the OpenFlow protocol. However, the Open
> vSwitch kernel portion is completely different from the OpenFlow
> reference implementation datapath and in fact does not speak OpenFlow
> at the kernel level.
Excellent.
Sorry - I may have misread the openflow code to be openvswitch.
> You brought up the point of keeping the kernel
> simple and making policy decisions in userspace. I completely agree
> and, in fact, that is the reason why Open vSwitch is designed the way
> it is.
>
> I think it might be helpful if I gave a high level overview of packet
> processing:
>
> When a packet is received it, the relevant fields from the packet are
> extracted and matched against a hash table. The most interesting part
> is actually what happens when the packets don't match a hash entry:
> they get sent up to userspace. It is userspace that makes a policy
> decision about the traffic and then pushes down a flow entry for
> future packets to match. Some of the things that those decisions can
> be based on include: OpenFlow rules, wildcarded entries, normal L2
> learning, etc. From then on, packets in that flow can be processed on
> the fast path in the kernel with minimal overhead, while still getting
> the benefit of the knowledge of userspace.
Ok, pretty classical stuff - exception handling in control path, update
policy to data path based on exception, subsequent stuff happens in data
path.
> So I think that we are actually in agreement on quite a number of
> points: the kernel should be kept as simple as possible, the control
> plane should be abstracted out and handled in userspace, and it should
> be possible to map the control rules (from OpenFlow or anywhere
> really) onto a simpler set of primitives for handling packets.
>
> So with those goals in mind, here's what is needed:
> 1. Packet field extraction and classification. Realistically speaking
> a new, specialized classifier would probably be needed, as you
> mention.
I think a new classifier would make life simpler here.
> 2. A mechanism to send/receive packets to/from userspace. This is an
> important component that Open vSwitch adds to the pipeline. This will
> probably expand in the future to suit different applications, like the
> security processing that I talked about.
There are many ways to skin that proverbial cat. I guess it will depend
on whether you are redirecting or merely copying a whole packet, or part
of it (while storing a part in the kernel) etc. Example for a scheme
that works using netlink look at the netfilter examples. You could use
pf_packet if merely requiring copies. One simple scheme i have used is
to have the mirred action redirect to a tun device on which a user space
daemon is listening. If you look at the mirred action - there is an
option to redirect to a named socket which was never implemented because
workarounds exist.
> 3. Output actions. A few exist today, at least some new ones will
> need to be added.
Agreed.
> So in reality, all of major components of Open vSwitch are actually
> not present in the kernel today. I know the argument could be made
> that certains parts can be replicated in different ways but that's
> back to the simplicity point that I was making earlier. The u32
> classifier isn't well suited for these types of rules and neither is
> pedit. If we're going to add the needed components either way, let's
> not make everyone's lives more complicated by mixing everything
> together.
I have to say it is a pleasant suprise that we agree. When i looked at
the openflow code i was worried. I always believe in improving what we
have in Linux than trying to add parallel competing interfaces.
[You'd be suprised for example on the number of vendors who put forward
the claim that they can route faster on Linux[1] by writing a little
barebone driver which ignores 99% of reality.]
cheers,
jamal
[1] I am forgiving on academics
^ permalink raw reply
* Re: [PATCH] net_sched: remove the unused parameter of qdisc_create_dflt()
From: jamal @ 2010-10-18 12:20 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, Stephen Hemminger, netdev, netem
In-Reply-To: <1287270248-13190-1-git-send-email-xiaosuo@gmail.com>
On Sun, 2010-10-17 at 07:04 +0800, Changli Gao wrote:
> The first parameter dev isn't in use in qdisc_create_dflt().
And we can derive it from netdev_queue if ever needed in the future.
Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
cheers,
jamal
^ permalink raw reply
* Re: [RFC PATCH 1/9] ipvs network name space aware
From: Hans Schillstrom @ 2010-10-18 13:23 UTC (permalink / raw)
To: Daniel Lezcano
Cc: lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, horms@verge.net.au, ja@ssi.bg,
wensong@linux-vs.org
In-Reply-To: <4CBC3182.80605@free.fr>
On Monday 18 October 2010 13:37:38 Daniel Lezcano wrote:
> On 10/18/2010 11:54 AM, Hans Schillstrom wrote:
> > On Monday 18 October 2010 10:59:25 Daniel Lezcano wrote:
> >
> >> On 10/08/2010 01:16 PM, Hans Schillstrom wrote:
> >>
> >>> This part contains the include files
> >>> where include/net/netns/ip_vs.h is new and contains all moved vars.
> >>>
> >>> SUMMARY
> >>>
> >>> include/net/ip_vs.h | 136 ++++---
> >>> include/net/net_namespace.h | 2 +
> >>> include/net/netns/ip_vs.h | 112 +++++
> >>>
> >>> Signed-off-by:Hans Schillstrom<hans.schillstrom@ericsson.com>
> >>> ---
> >>>
> >>>
> >>>
> >> [ ... ]
> >>
> >>
> >>> #ifdef CONFIG_IP_VS_IPV6
> >>> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> >>> index bd10a79..b59cdc5 100644
> >>> --- a/include/net/net_namespace.h
> >>> +++ b/include/net/net_namespace.h
> >>> @@ -15,6 +15,7 @@
> >>> #include<net/netns/ipv4.h>
> >>> #include<net/netns/ipv6.h>
> >>> #include<net/netns/dccp.h>
> >>> +#include<net/netns/ip_vs.h>
> >>> #include<net/netns/x_tables.h>
> >>> #if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
> >>> #include<net/netns/conntrack.h>
> >>> @@ -91,6 +92,7 @@ struct net {
> >>> struct sk_buff_head wext_nlevents;
> >>> #endif
> >>> struct net_generic *gen;
> >>> + struct netns_ipvs *ipvs;
> >>> };
> >>>
> >>>
> >> IMHO, it would be better to use the net_generic infra-structure instead
> >> of adding a new field in the netns structure.
> >>
> >>
> >>
> > I realized that to, but the performance penalty is quite high with net_generic :-(
> > But on the other hand if you are going to backport it, (without recompiling the kernel)
> > you gonna need it!
> >
>
> Hmm, yes. We don't want to have the init_net_ns performances to be impacted.
>
> You use here a pointer which will be dereferenced like the net_generic,
> I don't think there will be
> a big difference between using net_generic and using a pointer in the
> net namespace structure.
>
> The difference is the id usage, but this one is based on the idr which
> is quite fast.
>
I'm not so sure about that, have a look at net_generic and rcu_read_lock
and compare
ipvs = net->ipvs;
vs.
ipvs = net_generic(net, id)
static inline void *net_generic(struct net *net, int id)
{
struct net_generic *ng;
void *ptr;
rcu_read_lock();
ng = rcu_dereference(net->gen);
BUG_ON(id == 0 || id > ng->len);
ptr = ng->ptr[id - 1];
rcu_read_unlock();
return ptr;
}
...
static inline void rcu_read_lock(void)
{
__rcu_read_lock();
__acquire(RCU);
rcu_read_acquire();
}
Another way of doing it is to pass the ipvs ptr instead of the net ptr,
and add *net to the ipvs struct.
> We should experiment a bit here to compare both solutions.
Agre
>
I single stepped through the rcu_read_lock() on a x86_64
and it's quite many "stepi" that you need to enter :-(
> IMHO, we can (1) create a non-pointer netns_ipvs field in the net
> namespace structure or (2) use a pointer [with net_generic].
>
> (1) is the faster but with the drawback of having a bigger memory
> footprint even if the ipvs module is not loaded.
> In this case we have to take care of what we store in the netns_ipvs
> structure, that is reduce the per namespace table and so. At the first
> glance, I think we can reduce this to the sysctls and a very few data,
> for example using global tables tagged with the namespace and we don't
> break the cacheline alignment optimization.
>
> (2) is slower but as the memory is allocated and freed when the module
> is loaded/unloaded. What I don't like with this approach is we add some
> overhead even if the netns is not compiled in the kernel.
>
or (3)
Like (1) with data that needs to be cache aligned in "struct net"
and the rest in an ipvs struct.
Global hash tables or not ?
> > My sugestion, take both with a configuration switch like:
> > (i.e. avoid the rcu locking)
> >
> > --- net/ip_vs.h ---
> > ...
> > extern int ip_vs_net_id; /* net id for ip_vs */
> >
> >
> > static inline struct netns_ipvs * net_ipvs(struct net* net, int id) {
> > #ifdef CONFIG_IP_VS_FAST_NETNS
> > return net->ipvs;
> > #else
> > return (struct netns_ipvs *)net_generic(net, id);
> > #endif
> > }
> > ...
> >
> > and where you need the netns_ipvs struct ptr,
> > [snip]
> > struct ip_vs_conn *ip_vs_conn_in_get(struct net *net, ....
> > {
> > struct netns_ipvs *ipvs = net_ipvs(net, ip_vs_net_id);
> > ...
> >
>
> It is a nice way to wrap both solutions but at this point I don't think
> it is worth to add a 3rd option to compile ipvs.
>
>
--
Regards
Hans Schillstrom <hans.schillstrom@ericsson.com>
^ 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