* Re: [PATCH IPROUTE2] tc-codel: Add manpage
From: Dave Taht @ 2012-05-24 18:28 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: Eric Dumazet, netdev, Stephen Hemminger
In-Reply-To: <CAGK4HS8_O94rQZmvxeNjeYtbT3_a2C1FsZ9O=b9_n0vV2putdA@mail.gmail.com>
well, it would be nice if codel could sense it was on 10gigE or
greater, and self adjust.
On Thu, May 24, 2012 at 7:19 PM, Vijay Subramanian
<subramanian.vijay@gmail.com> wrote:
>>> +.SS target
>>> +Default and recommended value is 5ms.
>>
>> Although I can tell I prefer lower values on hosts.
>>
>> On 10Gbe links, I used 500us target
>>
>>> +.SS interval
>>> +give endpoints sufficient time to react. Default value is 100ms.
>>
>> Same here. In a datacenter, you might reduce this to 20ms or so...
>>
>
> Thanks for the insight. The paper does claim that codel can be run
> with the same setting, regardless of link rate.
> I guess reality is different.
>
> Thanks,
> Vijay
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
^ permalink raw reply
* [PATCH net-next 0/2] qlcnic: Bug fixes
From: Anirban Chakraborty @ 2012-05-24 18:06 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver
Please apply to net-next.
Thanks,
Anirban
^ permalink raw reply
* [PATCH 2/2] qlcnic: Fix unsupported CDRP command error message.
From: Anirban Chakraborty @ 2012-05-24 18:06 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Jitendra Kalsaria
In-Reply-To: <1337882816-2097-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
- Added proper error messages for unsupported FW commands
- Bumped up version to 5.0.29
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 8 ++++-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 34 +++++++++++++++++++---
2 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 520ff03..eaa1db9 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -36,8 +36,8 @@
#define _QLCNIC_LINUX_MAJOR 5
#define _QLCNIC_LINUX_MINOR 0
-#define _QLCNIC_LINUX_SUBVERSION 28
-#define QLCNIC_LINUX_VERSIONID "5.0.28"
+#define _QLCNIC_LINUX_SUBVERSION 29
+#define QLCNIC_LINUX_VERSIONID "5.0.29"
#define QLCNIC_DRV_IDC_VER 0x01
#define QLCNIC_DRIVER_VERSION ((_QLCNIC_LINUX_MAJOR << 16) |\
(_QLCNIC_LINUX_MINOR << 8) | (_QLCNIC_LINUX_SUBVERSION))
@@ -612,7 +612,11 @@ struct qlcnic_recv_context {
#define QLCNIC_CDRP_CMD_GET_MAC_STATS 0x00000037
#define QLCNIC_RCODE_SUCCESS 0
+#define QLCNIC_RCODE_INVALID_ARGS 6
#define QLCNIC_RCODE_NOT_SUPPORTED 9
+#define QLCNIC_RCODE_NOT_PERMITTED 10
+#define QLCNIC_RCODE_NOT_IMPL 15
+#define QLCNIC_RCODE_INVALID 16
#define QLCNIC_RCODE_TIMEOUT 17
#define QLCNIC_DESTROY_CTX_RESET 0
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
index cfa174d..b8ead69 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
@@ -53,12 +53,39 @@ qlcnic_issue_cmd(struct qlcnic_adapter *adapter, struct qlcnic_cmd_args *cmd)
rsp = qlcnic_poll_rsp(adapter);
if (rsp == QLCNIC_CDRP_RSP_TIMEOUT) {
- dev_err(&pdev->dev, "card response timeout.\n");
+ dev_err(&pdev->dev, "CDRP response timeout.\n");
cmd->rsp.cmd = QLCNIC_RCODE_TIMEOUT;
} else if (rsp == QLCNIC_CDRP_RSP_FAIL) {
cmd->rsp.cmd = QLCRD32(adapter, QLCNIC_ARG1_CRB_OFFSET);
- dev_err(&pdev->dev, "failed card response code:0x%x\n",
+ switch (cmd->rsp.cmd) {
+ case QLCNIC_RCODE_INVALID_ARGS:
+ dev_err(&pdev->dev, "CDRP invalid args: 0x%x.\n",
cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_NOT_SUPPORTED:
+ case QLCNIC_RCODE_NOT_IMPL:
+ dev_err(&pdev->dev,
+ "CDRP command not supported: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_NOT_PERMITTED:
+ dev_err(&pdev->dev,
+ "CDRP requested action not permitted: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_INVALID:
+ dev_err(&pdev->dev,
+ "CDRP invalid or unknown cmd received: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_TIMEOUT:
+ dev_err(&pdev->dev, "CDRP command timeout: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ default:
+ dev_err(&pdev->dev, "CDRP command failed: 0x%x.\n",
+ cmd->rsp.cmd);
+ }
} else if (rsp == QLCNIC_CDRP_RSP_OK) {
cmd->rsp.cmd = QLCNIC_RCODE_SUCCESS;
if (cmd->rsp.arg2)
@@ -957,9 +984,6 @@ int qlcnic_get_mac_stats(struct qlcnic_adapter *adapter,
mac_stats->mac_rx_jabber = le64_to_cpu(stats->mac_rx_jabber);
mac_stats->mac_rx_dropped = le64_to_cpu(stats->mac_rx_dropped);
mac_stats->mac_rx_crc_error = le64_to_cpu(stats->mac_rx_crc_error);
- } else {
- dev_info(&adapter->pdev->dev,
- "%s: Get mac stats failed =%d.\n", __func__, err);
}
dma_free_coherent(&adapter->pdev->dev, stats_size, stats_addr,
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: Timur Tabi @ 2012-05-24 18:28 UTC (permalink / raw)
To: David Daney
Cc: devicetree-discuss@lists.ozlabs.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FB6CBF1.40300@gmail.com>
David Daney wrote:
> Yes. You may note in the DTS file I attached in the parent (sorry for
> the fubar mime types), that there are two, almost identical, MDIO
> masters. smi0 has two directly attached PHYs. smi1 goes to the mux,
> and each child of the mux has four attached PHYs.
I'm till have trouble understanding all this. I'm just hacking things up
in order to help me understand it, but it's a slow and painful process.
This call in mdio_mux_init() is failing:
parent_bus = of_mdio_find_bus(parent_bus_node);
It returns NULL. Here is my MDIO node:
fman0: fman@400000 {
enet0: ethernet@e0000 {
tbi-handle = <&tbi0>;
phy-handle = <&phy0>;
phy-connection-type = "sgmii";
};
mdio0: mdio@e1120 {
gpios = <&gpio0 0 0
&gpio0 1 0>;
tbi0: tbi-phy@8 {
reg = <0x8>;
device_type = "tbi-phy";
};
phy0: ethernet-phy@1c {
reg = <0x1c>;
};
};
};
What am I missing? What do I need to do in order to get
of_mdio_find_bus() to return a real value?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH 1/2] qlcnic: Fix estimation of recv MSS in case of LRO
From: Anirban Chakraborty @ 2012-05-24 18:06 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Rajesh Borundia
In-Reply-To: <1337882816-2097-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
o Linux stack estimates MSS from skb->len or skb_shinfo(skb)->gso_size.
In case of LRO skb->len is aggregate of len of number of packets hence MSS
obtained using skb->len would be incorrect. Incorrect estimation of recv MSS
would lead to delayed acks in some traffic patterns (which sends two or three
packets and wait for ack and only then send remaining packets). This leads to
drop in performance. Hence we need to set gso_size to MSS obtained from firmware.
o This is fixed recently in firmware hence the MSS is obtained based on
capability. If fw is capable of sending the MSS then only driver sets the gso_size.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 7 +++++++
drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 3 +++
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h | 1 +
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 3 +++
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 9 +++++++++
5 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 8680a5d..520ff03 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -258,6 +258,8 @@ struct rcv_desc {
(((sts_data) >> 52) & 0x1)
#define qlcnic_get_lro_sts_seq_number(sts_data) \
((sts_data) & 0x0FFFFFFFF)
+#define qlcnic_get_lro_sts_mss(sts_data1) \
+ ((sts_data1 >> 32) & 0x0FFFF)
struct status_desc {
@@ -623,6 +625,7 @@ struct qlcnic_recv_context {
#define QLCNIC_CAP0_JUMBO_CONTIGUOUS (1 << 7)
#define QLCNIC_CAP0_LRO_CONTIGUOUS (1 << 8)
#define QLCNIC_CAP0_VALIDOFF (1 << 11)
+#define QLCNIC_CAP0_LRO_MSS (1 << 21)
/*
* Context state
@@ -829,6 +832,9 @@ struct qlcnic_mac_list_s {
#define QLCNIC_FW_CAPABILITY_FVLANTX BIT_9
#define QLCNIC_FW_CAPABILITY_HW_LRO BIT_10
#define QLCNIC_FW_CAPABILITY_MULTI_LOOPBACK BIT_27
+#define QLCNIC_FW_CAPABILITY_MORE_CAPS BIT_31
+
+#define QLCNIC_FW_CAPABILITY_2_LRO_MAX_TCP_SEG BIT_2
/* module types */
#define LINKEVENT_MODULE_NOT_PRESENT 1
@@ -918,6 +924,7 @@ struct qlcnic_ipaddr {
#define QLCNIC_NEED_FLR 0x1000
#define QLCNIC_FW_RESET_OWNER 0x2000
#define QLCNIC_FW_HANG 0x4000
+#define QLCNIC_FW_LRO_MSS_CAP 0x8000
#define QLCNIC_IS_MSI_FAMILY(adapter) \
((adapter)->flags & (QLCNIC_MSI_ENABLED | QLCNIC_MSIX_ENABLED))
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
index 8db8524..cfa174d 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
@@ -237,6 +237,9 @@ qlcnic_fw_cmd_create_rx_ctx(struct qlcnic_adapter *adapter)
| QLCNIC_CAP0_VALIDOFF);
cap |= (QLCNIC_CAP0_JUMBO_CONTIGUOUS | QLCNIC_CAP0_LRO_CONTIGUOUS);
+ if (adapter->flags & QLCNIC_FW_LRO_MSS_CAP)
+ cap |= QLCNIC_CAP0_LRO_MSS;
+
prq->valid_field_offset = offsetof(struct qlcnic_hostrq_rx_ctx,
msix_handler);
prq->txrx_sds_binding = nsds_rings - 1;
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
index 6ced319..28a6b28 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
@@ -588,6 +588,7 @@ enum {
#define CRB_DRIVER_VERSION (QLCNIC_REG(0x2a0))
#define CRB_FW_CAPABILITIES_1 (QLCNIC_CAM_RAM(0x128))
+#define CRB_FW_CAPABILITIES_2 (QLCNIC_CAM_RAM(0x12c))
#define CRB_MAC_BLOCK_START (QLCNIC_CAM_RAM(0x1c0))
/*
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
index d32cf0d..f5a0ddc 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
@@ -1654,6 +1654,9 @@ qlcnic_process_lro(struct qlcnic_adapter *adapter,
length = skb->len;
+ if (adapter->flags & QLCNIC_FW_LRO_MSS_CAP)
+ skb_shinfo(skb)->gso_size = qlcnic_get_lro_sts_mss(sts_data1);
+
if (vid != 0xffff)
__vlan_hwaccel_put_tag(skb, vid);
netif_receive_skb(skb);
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index 46e77a2..707b5ca 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -1136,6 +1136,8 @@ static int
__qlcnic_up(struct qlcnic_adapter *adapter, struct net_device *netdev)
{
int ring;
+ u32 capab2;
+
struct qlcnic_host_rds_ring *rds_ring;
if (adapter->is_up != QLCNIC_ADAPTER_UP_MAGIC)
@@ -1146,6 +1148,12 @@ __qlcnic_up(struct qlcnic_adapter *adapter, struct net_device *netdev)
if (qlcnic_set_eswitch_port_config(adapter))
return -EIO;
+ if (adapter->capabilities & QLCNIC_FW_CAPABILITY_MORE_CAPS) {
+ capab2 = QLCRD32(adapter, CRB_FW_CAPABILITIES_2);
+ if (capab2 & QLCNIC_FW_CAPABILITY_2_LRO_MAX_TCP_SEG)
+ adapter->flags |= QLCNIC_FW_LRO_MSS_CAP;
+ }
+
if (qlcnic_fw_create_ctx(adapter))
return -EIO;
@@ -1215,6 +1223,7 @@ __qlcnic_down(struct qlcnic_adapter *adapter, struct net_device *netdev)
qlcnic_napi_disable(adapter);
qlcnic_fw_destroy_ctx(adapter);
+ adapter->flags &= ~QLCNIC_FW_LRO_MSS_CAP;
qlcnic_reset_rx_buffers_list(adapter);
qlcnic_release_tx_buffers(adapter);
--
1.7.1
^ permalink raw reply related
* [PATCH IPROUTE2] tc-codel: Update usage text
From: Vijay Subramanian @ 2012-05-24 18:48 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, Eric Dumazet, Dave Taht, Vijay Subramanian
codel can take 'noecn' as an option. This also makes it consistent with the
manpage.
Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
---
tc/q_codel.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tc/q_codel.c b/tc/q_codel.c
index 826285a..dc4b3f6 100644
--- a/tc/q_codel.c
+++ b/tc/q_codel.c
@@ -54,7 +54,7 @@
static void explain(void)
{
fprintf(stderr, "Usage: ... codel [ limit PACKETS ] [ target TIME]\n");
- fprintf(stderr, " [ interval TIME ] [ ecn ]\n");
+ fprintf(stderr, " [ interval TIME ] [ ecn | noecn ]\n");
}
static int codel_parse_opt(struct qdisc_util *qu, int argc, char **argv,
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: David Daney @ 2012-05-24 18:50 UTC (permalink / raw)
To: Timur Tabi
Cc: devicetree-discuss@lists.ozlabs.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FBE7DD8.509@freescale.com>
On 05/24/2012 11:28 AM, Timur Tabi wrote:
> David Daney wrote:
>> Yes. You may note in the DTS file I attached in the parent (sorry for
>> the fubar mime types), that there are two, almost identical, MDIO
>> masters. smi0 has two directly attached PHYs. smi1 goes to the mux,
>> and each child of the mux has four attached PHYs.
>
> I'm till have trouble understanding all this. I'm just hacking things up
> in order to help me understand it, but it's a slow and painful process.
>
> This call in mdio_mux_init() is failing:
>
> parent_bus = of_mdio_find_bus(parent_bus_node);
>
Well, the MDIO bus must have an associated device tree node.
For my OCTEON code, the MDIO bus device is created as a result of the
call to of_platform_bus_probe(), which takes care of filling in all the
device tree nodes of the devices it finds and creates.
> It returns NULL. Here is my MDIO node:
>
> fman0: fman@400000 {
> enet0: ethernet@e0000 {
> tbi-handle =<&tbi0>;
> phy-handle =<&phy0>;
> phy-connection-type = "sgmii";
> };
>
> mdio0: mdio@e1120 {
> gpios =<&gpio0 0 0
> &gpio0 1 0>;
>
> tbi0: tbi-phy@8 {
> reg =<0x8>;
> device_type = "tbi-phy";
> };
>
> phy0: ethernet-phy@1c {
> reg =<0x1c>;
> };
> };
> };
>
> What am I missing?
For starters, I do not see any compatible properties that would allow
the proper drivers to be bound to anything.
Also I see no MDIO mux node there, so it is unclear why you are even
asking these questions.
David Daney
^ permalink raw reply
* Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: Timur Tabi @ 2012-05-24 19:03 UTC (permalink / raw)
To: David Daney
Cc: devicetree-discuss@lists.ozlabs.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FBE82F2.6080100@gmail.com>
David Daney wrote:
> Well, the MDIO bus must have an associated device tree node.
>
> For my OCTEON code, the MDIO bus device is created as a result of the
> call to of_platform_bus_probe(), which takes care of filling in all the
> device tree nodes of the devices it finds and creates.
Ok, let me give you some background. We actually already have MDIO muxing
code in-house, but it's different from yours. So now I'm rewriting it to
use your design instead.
So our current code looks for "virtual MDIO nodes", and we call
mdiobus_alloc() and then of_mdiobus_register(). I think this is what I'm
missing now.
I just don't know what to do next. Part of the problem is that I don't
have much experience with MDIO drivers.
>> It returns NULL. Here is my MDIO node:
>>
>> fman0: fman@400000 {
>> enet0: ethernet@e0000 {
>> tbi-handle =<&tbi0>;
>> phy-handle =<&phy0>;
>> phy-connection-type = "sgmii";
>> };
>>
>> mdio0: mdio@e1120 {
>> gpios =<&gpio0 0 0
>> &gpio0 1 0>;
>>
>> tbi0: tbi-phy@8 {
>> reg =<0x8>;
>> device_type = "tbi-phy";
>> };
>>
>> phy0: ethernet-phy@1c {
>> reg =<0x1c>;
>> };
>> };
>> };
>>
>> What am I missing?
>
> For starters, I do not see any compatible properties that would allow
> the proper drivers to be bound to anything.
Ok, that makes sense.
> Also I see no MDIO mux node there, so it is unclear why you are even
> asking these questions.
I only gave you part of the device tree. Here's my mdio mux node:
mdio-mux {
compatible = "mdio-mux-gpio";
gpios = <&gpio0 0 0>, <&gpio0 1 0>;
mdio-parent-bus = <&mdio0>;
#address-cells = <1>;
#size-cells = <0>;
mdio@2 {
reg = <2>;
#address-cells = <1>;
#size-cells = <0>;
phy21: ethernet-phy@1 {
reg = <1>;
// compatible = "marvell,88e1149r", "ethernet-phy-ieee802.3-c22";
marvell,reg-init = <3 0x10 0 0x5777>,
<3 0x11 0 0x00aa>,
<3 0x12 0 0x4105>,
<3 0x13 0 0x0a60>;
interrupt-parent = <&gpio0>;
// interrupts = <10 8>; /* Pin 10, active low */
};
};
};
};
>
> David Daney
>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: David Daney @ 2012-05-24 19:19 UTC (permalink / raw)
To: Timur Tabi
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <4FBE8605.2020507-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
On 05/24/2012 12:03 PM, Timur Tabi wrote:
> David Daney wrote:
>
>> Well, the MDIO bus must have an associated device tree node.
>>
>> For my OCTEON code, the MDIO bus device is created as a result of the
>> call to of_platform_bus_probe(), which takes care of filling in all the
>> device tree nodes of the devices it finds and creates.
>
> Ok, let me give you some background. We actually already have MDIO muxing
> code in-house, but it's different from yours. So now I'm rewriting it to
> use your design instead.
>
> So our current code looks for "virtual MDIO nodes", and we call
> mdiobus_alloc() and then of_mdiobus_register(). I think this is what I'm
> missing now.
>
> I just don't know what to do next.
You will have to debug it and find out why the device match is failing,
then fix it.
David Daney
^ permalink raw reply
* Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label
From: Paul Gortmaker @ 2012-05-24 19:58 UTC (permalink / raw)
To: David Miller; +Cc: jon.maloy, netdev, tipc-discussion, allan.stephens, maloy
In-Reply-To: <20120521.023926.548567931208958037.davem@davemloft.net>
[Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label] On 21/05/2012 (Mon 02:39) David Miller wrote:
> From: Jon Maloy <jon.maloy@ericsson.com>
> Date: Mon, 21 May 2012 01:59:12 -0400
>
> > With the latest series of patches from Paul Gortmaker and Allan
> > Stephens TIPC is now functionally mature and stable enough to
> > justify removal of the EXPERIMENTAL label.
> >
> > Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
>
> I'll let Paul Gortmaker decide whether this is warranted or
> not.
The EXPERIMENTAL thing has always been rather subjective, but
I'd like to see some level of confidence that a crafted up bogus
TIPC message can't be used to DOS a machine with active TIPC
connections before removing EXPERIMENTAL. Maybe the current code
is OK as-is in this respect but I'd feel better knowing that it
had been audited with this exact kind of thing in mind.
>
> I don't really want to all of a sudden start seeing patches from
> people like you and the windriver folks, who effectively wrote off
> upstream and left poor Paul Gortmaker holding the bag and having to
> take care of EVERYTHING.
To be fair, I should note that Al did a lot of work in the background
getting commits onto a modern baseline and answering all my questions
since the out of tree sourceforge mess was highlighted here on netdev.
>
> You can't just do nothing for years, end up making someone else
> do it, then say "Hey here I am, I feel like submitting upstream
> patches now" after I've spent this entire time starting to trust
> Paul for TIPC patches.
I've been thinking about this off and on, and I'm wondering what to
suggest going forward. Dealing with the backlog was largely going over
maintenance and bugfix type patches and sanitizing them for integration
upstream. It largely boiled down to being able to tell a crap patch
from a good one that matched upstream expectations. I figured I could
manage to not screw that up too badly, hence why I volunteered to assist
with the backlog.
But for new TIPC development features, future direction, and things like
that -- making the right call requires intimate understanding of TIPC
and its users, which is something that a maintainer should have but
something I know I don't have. (A man has to know his limitations.)
In this context, I'm not talking about these three trivial patches; but
more complicated stuff that I imagine will be floated in the future.
To that end, I can still review and call out issues in a crap patch when
I see them. But I'd like to see new stuff sent to netdev, so that folks
smarter than me have a chance to catch when a patch appears generally OK
but is architecturally the wrong direction etc.
Paul.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply
* pch_gbe: backport fails to start sending
From: Andy Cress @ 2012-05-24 20:05 UTC (permalink / raw)
To: netdev
Folks,
I now have a different case where the pch_gbe driver needs help.
I have backported the pch_gbe git head (v1.00) to kernel 2.6.32
(RHEL6.2) and when it loads, after the open completes and the link is
up, it fails to start sending and receiving.
I also took the pch_gbe source which runs fine on 2.6.38 (Fedora 15) and
backported it, and get the same results.
The much bulkier pch_gbe 0.91-NAPI driver does run on 2.6.32 (RHEL6.2)
but is not maintained.
I also tried backporting the mii.c from the 2.6.38 kernel, but that
didn't help, got the same symptoms.
After adding -DDEBUG to the 1.00 driver, I can see that it seems to get
just DMA Complete interrupts when it should be getting Transmit
complete, etc. I'm not sure why it gets stuck there.
Any ideas/input is welcome.
Andy
https://sendfile.kontron.com/message/KJKmrf171EhsuvbyhjnXpe
Attached at this link are two files:
pch_gbe-100a.tar.gz = the backported pch_gbe 1.00 head source, includes
patches that were applied.
dmesg.tar.gz = Some dmesg output from test cases with debug:
dmesg-pch10a-kern2632-bad.txt = backported 1.00 from git head on
kernel 2.6.32, fails
dmesg-pch10-kern2632-bad.txt = backported 1.00 from Fedora 15 on
kernel 2.6.32, fails
dmesg-pch10-kern2638-good.txt = same 1.00 source from Fedora 15 on
kernel 2.6.38, works
^ permalink raw reply
* Re: [PATCH net-next 0/2] qlcnic: Bug fixes
From: David Miller @ 2012-05-24 20:06 UTC (permalink / raw)
To: anirban.chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1337882816-2097-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Thu, 24 May 2012 14:06:54 -0400
> Please apply to net-next.
As I've stated at least 10 times this week, net-next is not open
and therefore submitting patches for net-next is not appropriate.
If people are not going to even read my announcements and
notifications of the states of the various GIT trees, I might as well
not make them at all.
^ permalink raw reply
* Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label
From: David Miller @ 2012-05-24 20:12 UTC (permalink / raw)
To: paul.gortmaker; +Cc: jon.maloy, netdev, tipc-discussion, allan.stephens, maloy
In-Reply-To: <20120524195816.GA6487@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 24 May 2012 15:58:16 -0400
> But for new TIPC development features, future direction, and things like
> that -- making the right call requires intimate understanding of TIPC
> and its users, which is something that a maintainer should have but
> something I know I don't have. (A man has to know his limitations.)
>
> In this context, I'm not talking about these three trivial patches; but
> more complicated stuff that I imagine will be floated in the future.
>
> To that end, I can still review and call out issues in a crap patch when
> I see them. But I'd like to see new stuff sent to netdev, so that folks
> smarter than me have a chance to catch when a patch appears generally OK
> but is architecturally the wrong direction etc.
For maintainership, taste is more important than deep knowledge of the
specific technology. Worst case you ask the submitter to explain the
background of their change more thoroughly and that information is an
absolutely requirement in the commit message and code comments
anyways.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply
* Re: pch_gbe: backport fails to start sending
From: David Miller @ 2012-05-24 20:13 UTC (permalink / raw)
To: andy.cress; +Cc: netdev
In-Reply-To: <40680C535D6FE6498883F1640FACD44DEA6714@ka-exchange-1.kontronamerica.local>
From: "Andy Cress" <andy.cress@us.kontron.com>
Date: Thu, 24 May 2012 13:05:05 -0700
> I have backported the pch_gbe git head (v1.00) to kernel 2.6.32
> (RHEL6.2) and when it loads, after the open completes and the link is
> up, it fails to start sending and receiving.
Nobody here is going to help you with a vendor kernel backport,
sorry. You're on your own.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS
From: David Miller @ 2012-05-24 20:21 UTC (permalink / raw)
To: jhs, hadi; +Cc: netdev
In-Reply-To: <1337863502.3513.15.camel@mojatatu>
From: jamal <hadi@cyberus.ca>
Date: Thu, 24 May 2012 08:45:02 -0400
> After about two decades, I am giving up on cyberus.
> Nabwaga Manyanga.
>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Applied.
^ permalink raw reply
* Re: [PATCH] xen/netback: Calculate the number of SKB slots required correctly
From: David Miller @ 2012-05-24 20:21 UTC (permalink / raw)
To: simon.graham
Cc: Ian.Campbell, konrad.wilk, xen-devel, netdev, bhutchings,
adnan.misherfi
In-Reply-To: <1337876767-16041-1-git-send-email-simon.graham@citrix.com>
From: Simon Graham <simon.graham@citrix.com>
Date: Thu, 24 May 2012 12:26:07 -0400
> When calculating the number of slots required for a packet header, the code
> was reserving too many slots if the header crossed a page boundary. Since
> netbk_gop_skb copies the header to the start of the page, the count of
> slots required for the header should be based solely on the header size.
>
> This problem is easy to reproduce if a VIF is bridged to a USB 3G modem
> device as the skb->data value always starts near the end of the first page.
>
> Signed-off-by: Simon Graham <simon.graham@citrix.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net/wanrouter: Deprecate and schedule for removal
From: David Miller @ 2012-05-24 20:21 UTC (permalink / raw)
To: joe; +Cc: shemminger, greearb, jan.ceuleers, netdev
In-Reply-To: <1337879610.5070.17.camel@joe2Laptop>
From: Joe Perches <joe@perches.com>
Date: Thu, 24 May 2012 10:13:30 -0700
> No one uses this on current kernels anymore.
>
> Let it be known it's going to be removed eventually.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: Add Sierra Wireless device IDs
From: David Miller @ 2012-05-24 20:21 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb
In-Reply-To: <1337851172-28549-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Thu, 24 May 2012 11:19:32 +0200
> Some additional Gobi3K IDs found in the BSD/GPL licensed
> out-of-tree GobiNet driver from Sierra Wireless.
>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied.
^ permalink raw reply
* Re: [PATCH] solos-pci: Fix DMA support
From: David Miller @ 2012-05-24 20:21 UTC (permalink / raw)
To: dwmw2; +Cc: netdev, nathan
In-Reply-To: <1337871507.26314.132.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 24 May 2012 15:58:27 +0100
> DMA support has finally made its way to the top of the TODO list, having
> realised that a Geode using MMIO can't keep up with two ADSL2+ lines
> each running at 21Mb/s.
>
> This patch fixes a couple of bugs in the DMA support in the driver, so
> once the corresponding FPGA update is complete and tested everything
> should work properly.
>
> We weren't storing the currently-transmitting skb, so we were never
> unmapping it and never freeing/popping it when the TX was done.
> And the addition of pci_set_master() is fairly self-explanatory.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/2] qlcnic: Bug fixes
From: Joe Perches @ 2012-05-24 20:24 UTC (permalink / raw)
To: David Miller; +Cc: anirban.chakraborty, netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <20120524.160659.834400122540802357.davem@davemloft.net>
On Thu, 2012-05-24 at 16:06 -0400, David Miller wrote:
> From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
> Date: Thu, 24 May 2012 14:06:54 -0400
>
> > Please apply to net-next.
>
> As I've stated at least 10 times this week, net-next is not open
> and therefore submitting patches for net-next is not appropriate.
> If people are not going to even read my announcements and
> notifications of the states of the various GIT trees, I might as well
> not make them at all.
Perhaps setup a patchwork bot to autoreply to the
sender only that these won't be looked at until
after the merge window closes and train yourself
to ignore the patchwork queue until then?
^ permalink raw reply
* Re: [PATCH net-next 0/2] qlcnic: Bug fixes
From: Anirban Chakraborty @ 2012-05-24 20:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dept-NX Linux NIC Driver
In-Reply-To: <20120524.160659.834400122540802357.davem@davemloft.net>
On 5/24/12 1:06 PM, "David Miller" <davem@davemloft.net> wrote:
>From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
>Date: Thu, 24 May 2012 14:06:54 -0400
>
>> Please apply to net-next.
>
>As I've stated at least 10 times this week, net-next is not open
>and therefore submitting patches for net-next is not appropriate.
>
>If people are not going to even read my announcements and
>notifications of the states of the various GIT trees, I might as well
>not make them at all.
My mistake, will resend it when the window opens. Sorry for the trouble.
-Anirban
^ permalink raw reply
* Re: [PATCH net-next 0/2] qlcnic: Bug fixes
From: David Miller @ 2012-05-24 20:28 UTC (permalink / raw)
To: joe; +Cc: anirban.chakraborty, netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1337891078.5070.36.camel@joe2Laptop>
From: Joe Perches <joe@perches.com>
Date: Thu, 24 May 2012 13:24:38 -0700
> On Thu, 2012-05-24 at 16:06 -0400, David Miller wrote:
>> From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
>> Date: Thu, 24 May 2012 14:06:54 -0400
>>
>> > Please apply to net-next.
>>
>> As I've stated at least 10 times this week, net-next is not open
>> and therefore submitting patches for net-next is not appropriate.
>
>> If people are not going to even read my announcements and
>> notifications of the states of the various GIT trees, I might as well
>> not make them at all.
>
> Perhaps setup a patchwork bot to autoreply to the
> sender only that these won't be looked at until
> after the merge window closes and train yourself
> to ignore the patchwork queue until then?
Sorry, people simply need to learn when it's appropriate to
submit patches.
Forcing them to resend at the appropriate time will train
their minds to take such things into consideration.
And if it's too bothersome to get them to resubmit, perhaps
they don't consider their patch important enough after all.
That's why we always handle situations like this by dropping things
and asking for a resend.
^ permalink raw reply
* [PATCH v4] xfrm: take net hdr len into account for esp payload size calculation
From: Benjamin Poirier @ 2012-05-24 21:32 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, linux-kernel,
Steffen Klassert, Diego Beltrami
In-Reply-To: <20120517.200509.2290282427866555176.davem@davemloft.net>
Corrects the function that determines the esp payload size. The calculations
done in esp{4,6}_get_mtu() lead to overlength frames in transport mode for
certain mtu values and suboptimal frames for others.
According to what is done, mainly in esp{,6}_output() and tcp_mtu_to_mss(),
net_header_len must be taken into account before doing the alignment
calculation.
Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
---
Changes since v3:
* also fix ipv6
Changes since v2:
* rename l3_adj to net_adj
* fix indentation
Changes since v1:
* introduce l3_adj to preserve the same returned value as before for tunnel
mode
For example:
* on ipv4 with md5 AH and 3des ESP (transport mode):
mtu = 1499 leads to FRAGFAILS
mtu = 1500 the addition of padding in the esp header could be avoided
* on ipv6 with md5 AH and twofish-sha1 ESP (transport mode):
mtu = 1491 leads to Ip6FragFails
mtu = 1499 padding can be avoided
For details on how the formula is established, see
https://lkml.org/lkml/2012/5/10/597
Tested with
* transport mode E
* transport mode EA
* transport mode E + ah
* tunnel mode E
Not tested with BEET, but it should be the same as transport mode
draft-nikander-esp-beet-mode-03.txt Section 5.2:
"The wire packet format is identical to the ESP transport mode"
---
net/ipv4/esp4.c | 24 +++++++++---------------
net/ipv6/esp6.c | 18 +++++++-----------
2 files changed, 16 insertions(+), 26 deletions(-)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 89a47b3..cb982a6 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -459,28 +459,22 @@ static u32 esp4_get_mtu(struct xfrm_state *x, int mtu)
struct esp_data *esp = x->data;
u32 blksize = ALIGN(crypto_aead_blocksize(esp->aead), 4);
u32 align = max_t(u32, blksize, esp->padlen);
- u32 rem;
-
- mtu -= x->props.header_len + crypto_aead_authsize(esp->aead);
- rem = mtu & (align - 1);
- mtu &= ~(align - 1);
+ unsigned int net_adj;
switch (x->props.mode) {
- case XFRM_MODE_TUNNEL:
- break;
- default:
case XFRM_MODE_TRANSPORT:
- /* The worst case */
- mtu -= blksize - 4;
- mtu += min_t(u32, blksize - 4, rem);
- break;
case XFRM_MODE_BEET:
- /* The worst case. */
- mtu += min_t(u32, IPV4_BEET_PHMAXLEN, rem);
+ net_adj = sizeof(struct iphdr);
break;
+ case XFRM_MODE_TUNNEL:
+ net_adj = 0;
+ break;
+ default:
+ BUG();
}
- return mtu - 2;
+ return ((mtu - x->props.header_len - crypto_aead_authsize(esp->aead) -
+ net_adj) & ~(align - 1)) + (net_adj - 2);
}
static void esp4_err(struct sk_buff *skb, u32 info)
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 1e62b75..db1521f 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -413,19 +413,15 @@ static u32 esp6_get_mtu(struct xfrm_state *x, int mtu)
struct esp_data *esp = x->data;
u32 blksize = ALIGN(crypto_aead_blocksize(esp->aead), 4);
u32 align = max_t(u32, blksize, esp->padlen);
- u32 rem;
+ unsigned int net_adj;
- mtu -= x->props.header_len + crypto_aead_authsize(esp->aead);
- rem = mtu & (align - 1);
- mtu &= ~(align - 1);
-
- if (x->props.mode != XFRM_MODE_TUNNEL) {
- u32 padsize = ((blksize - 1) & 7) + 1;
- mtu -= blksize - padsize;
- mtu += min_t(u32, blksize - padsize, rem);
- }
+ if (x->props.mode != XFRM_MODE_TUNNEL)
+ net_adj = sizeof(struct ipv6hdr);
+ else
+ net_adj = 0;
- return mtu - 2;
+ return ((mtu - x->props.header_len - crypto_aead_authsize(esp->aead) -
+ net_adj) & ~(align - 1)) + (net_adj - 2);
}
static void esp6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
--
1.7.7
^ permalink raw reply related
* Re: [PATCH IPROUTE2] tc-codel: Update usage text
From: Stephen Hemminger @ 2012-05-24 22:02 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: netdev, Eric Dumazet, Dave Taht
In-Reply-To: <1337885287-31354-1-git-send-email-subramanian.vijay@gmail.com>
On Thu, 24 May 2012 11:48:07 -0700
Vijay Subramanian <subramanian.vijay@gmail.com> wrote:
> codel can take 'noecn' as an option. This also makes it consistent with the
> manpage.
>
> Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
> ---
> tc/q_codel.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/tc/q_codel.c b/tc/q_codel.c
> index 826285a..dc4b3f6 100644
> --- a/tc/q_codel.c
> +++ b/tc/q_codel.c
> @@ -54,7 +54,7 @@
> static void explain(void)
> {
> fprintf(stderr, "Usage: ... codel [ limit PACKETS ] [ target TIME]\n");
> - fprintf(stderr, " [ interval TIME ] [ ecn ]\n");
> + fprintf(stderr, " [ interval TIME ] [ ecn | noecn ]\n");
> }
>
> static int codel_parse_opt(struct qdisc_util *qu, int argc, char **argv,
Applied, thanks.
^ permalink raw reply
* Re: [ovs-dev] [PATCH 04/21] vswitchd: Add iface_parse_tunnel
From: Simon Horman @ 2012-05-24 23:59 UTC (permalink / raw)
To: Ben Pfaff; +Cc: dev, netdev
In-Reply-To: <20120524164738.GE26173@nicira.com>
On Thu, May 24, 2012 at 09:47:38AM -0700, Ben Pfaff wrote:
> The concept seems OK to me here. I have only a few minor comments.
>
> On Thu, May 24, 2012 at 06:08:57PM +0900, Simon Horman wrote:
> > +#define TNL_F_CSUM (1 << 0) /* Checksum packets. */
> > +#define TNL_F_TOS_INHERIT (1 << 1) /* Inherit ToS from inner packet. */
> > +#define TNL_F_TTL_INHERIT (1 << 2) /* Inherit TTL from inner packet. */
> > +#define TNL_F_DF_INHERIT (1 << 3) /* Inherit DF bit from inner packet. */
> > +#define TNL_F_DF_DEFAULT (1 << 4) /* Set DF bit if inherit off or
> > + * not IP. */
> > +#define TNL_F_PMTUD (1 << 5) /* Enable path MTU discovery. */
> > +#define TNL_F_HDR_CACHE (1 << 6) /* Enable tunnel header caching. */
> > +#define TNL_F_IPSEC (1 << 7) /* Traffic is IPsec encrypted. */
> > +#define TNL_F_IN_KEY (1 << 8) /* Tunnel port has input key. */
> > +#define TNL_F_OUT_KEY (1 << 9) /* Tunnel port has output key. */
>
> Some of the above definitions use all spaces, others use tabs. It's
> OVS userspace code so it's better to use all spaces, I think.
Sorry about that. I have a bit of trouble remembering to switch
tabbing modes in my editor depending on if I am in user-space or the
datapath.
> > + if (is_ipsec) {
> > + char *file_name = xasprintf("%s/%s", ovs_rundir(),
> > + "ovs-monitor-ipsec.pid");
> > + pid_t pid = read_pidfile(file_name);
> > + free(file_name);
> > + if (pid < 0) {
> > + VLOG_ERR("%s: IPsec requires the ovs-monitor-ipsec daemon",
> > + iface_cfg->name);
> > + goto err;
> > + }
>
> I just noticed that we re-read this pidfile every time we parse an
> IPsec tunnel. I guess that would be a big waste of time if we have a
> lot of IPsec tunnels. I'll make a note to consider fixing this
> separately (it's not your problem).
I guess that it should be easy enough to set a flag if any of the parsed
configurations use ipsec and perform the pid check if so.
As it is, I wouldn't be at all surprised if my series breaks ipsec as
I haven't tested it (with or without my changes).
^ 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