* linux-next: net tree build warning
From: Stephen Rothwell @ 2009-09-04 4:28 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-next, linux-kernel, roel kluin, netdev
[-- Attachment #1: Type: text/plain, Size: 583 bytes --]
Hi Dave,
Today's linux-next build (x86_64 allmodconfig gcc-4.4.0) produced this
warning:
drivers/net/wan/dscc4.c: In function 'dscc4_rx_skb':
drivers/net/wan/dscc4.c:670: warning: suggest parentheses around comparison in operand of '|'
which actually points out a bug, I think. It is doing
(x & (y | z)) != y | z
when it probably means
(x & (y | z)) != (y | z)
Introduced by commit 5de3fcab91b0e1809eec030355d15801daf25083 ("WAN: bit
and/or confusion").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [net-next PATCH 2/3] ixgbe: Distribute transmission of FCoE traffic in 82599
From: Waskiewicz Jr, Peter P @ 2009-09-04 4:12 UTC (permalink / raw)
To: David Miller
Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org, gospo@redhat.com,
Zou, Yi
In-Reply-To: <20090903.200915.157113657.davem@davemloft.net>
On Thu, 3 Sep 2009, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Thu, 03 Sep 2009 17:56:10 -0700
>
> > From: Yi Zou <yi.zou@intel.com>
> >
> > This adds a simple selection of a FCoE tx queue based on the current cpu id to
> > distribute transmission of FCoE traffic evenly among multiple FCoE transmit
> > queues.
> >
> > Signed-off-by: Yi Zou <yi.zou@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Applied.
>
> Does it matter that arbitrary programs or other stacks could transmit
> ETH_P_FCOE traffic as well? Would that interfere with how this offload
> hardware works now that you're directing all ETH_P_FCOE traffic to
> FCOE rings?
If another stack uses the FCoE Ethertype, the filtering we use in the
qdisc layer to filter FCoE frames would assume they belong in the FCoE
flow ID in the driver. As long as the other stacks send standard FCoE
frames, there won't be a problem. If a stack uses the Ethertype but
doesn't follow the standard FCoE frame format, then I'd say that stack was
in need of being fixed.
The FCoE offload on Tx in 82599 is basically just a segmenter, like TSO.
Cheers,
-PJ
^ permalink raw reply
* Re: [net-next PATCH 1/3] ixgbe: Add support for multiple Tx queues for FCoE in 82599
From: Waskiewicz Jr, Peter P @ 2009-09-04 4:06 UTC (permalink / raw)
To: David Miller
Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org, gospo@redhat.com,
Zou, Yi
In-Reply-To: <20090903.200809.212485138.davem@davemloft.net>
On Thu, 3 Sep 2009, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Thu, 03 Sep 2009 17:55:50 -0700
>
> > From: Yi Zou <yi.zou@intel.com>
> >
> > This patch adds support for multiple transmit queues to the Fiber Channel
> > over Ethernet (FCoE) feature found in 82599. Currently, FCoE has multiple
> > Rx queues available, along with a redirection table, that helps distribute
> > the I/O load across multiple CPUs based on the FC exchange ID. To make
> > this the most effective, we need to provide the same layout of transmit
> > queues to match receive.
> >
> > Particularly, when Data Center Bridging (DCB) is enabled, the designated
> > traffic class for FCoE can have dedicated queues for just FCoE traffic,
> > while not affecting any other type of traffic flow.
> >
> > Signed-off-by: Yi Zou <yi.zou@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Applied.
>
> So does this eat into the TX queues available to non-FCOE traffic
> or is this a shared setup?
When DCB is enabled, then this is purely isolated to the FCoE traffic
class. When DCB is enabled, all the queues in the hardware are
hard-partitioned. Since our FCoE implementation sets a different MTU, and
also disables packet split, to the FCoE queues, these are completely
isolated.
Now when DCB is not enabled, 82599 operates in a kind of HBA-ish mode.
FCoE and LAN will be running on the same queues, so yes, these queues
would be eaten up from the LAN queues.
That all being said, 82599 has 128 Tx queues available. But we only
enable 1 queue per online CPU in today's driver without FCoE, so we won't
run out of queues (yet).
Cheers,
-PJ
^ permalink raw reply
* Re: [PATCH net-next] can: add can_free_echo_skb() for upcoming drivers
From: David Miller @ 2009-09-04 3:46 UTC (permalink / raw)
To: wg; +Cc: netdev, socketcan-core, urs.thuermann, oliver.hartkopp
In-Reply-To: <4A9D3D14.90201@grandegger.com>
Can a CAN expert please review these patches? They are rotting
in patchwork and I want to move forward with them somehow.
Thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: Fix tcp_v6_send_response(): it didn't set skb transport header
From: David Miller @ 2009-09-04 3:45 UTC (permalink / raw)
To: cratiu; +Cc: netdev
In-Reply-To: <200909031925.54197.cratiu@ixiacom.com>
From: Cosmin Ratiu <cratiu@ixiacom.com>
Date: Thu, 3 Sep 2009 19:25:53 +0300
> Hello,
>
> Here is a patch which fixes an issue observed when using TCP over IPv6 and AH
> from IPsec.
>
> When a connection gets closed the 4-way method and the last ACK from the
> server gets dropped, the subsequent FINs from the client do not get ACKed
> because tcp_v6_send_response does not set the transport header pointer. This
> causes ah6_output to try to allocate a lot of memory, which typically fails,
> so the ACKs never make it out of the stack.
>
> I have reproduced the problem on kernel 2.6.7, but after looking at the latest
> kernel it seems the problem is still there.
>
> Signed-off-by: Cosmin Ratiu <cratiu@ixiacom.com>
Great catch. IPV4 handles this transparently via ip_append_data()
which is what it uses to send these kinds of frames. IPV6 does
this stuff by hand.
Applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH NEXT 1/3] netxen: fix lro buffer allocation
From: David Miller @ 2009-09-04 3:33 UTC (permalink / raw)
To: dhananjay.phadke; +Cc: davem, netdev
In-Reply-To: <7608421F3572AB4292BB2532AE89D565865FA8A557@AVEXMB1.qlogic.org>
From: Dhananjay Phadke <dhananjay.phadke@qlogic.com>
Date: Thu, 3 Sep 2009 20:24:15 -0700
>> But if the page allocator can't satisfy allocation requests
>> it doesn't matter how many microseconds you're saving here.
>>
>> I think you're priorities are backwards.
>
> Ok whatever. Whether I request 9k or 12k, page allocator
> is digging 16k chunks.
>
> When there's enough memory, every cycle saved is important
> for firmware. I would love to enable fragmented rx, if it's
> not affecting throughput.
Ok.
Just FYI I won't be surprised if SLAB/SLUB/SLQB at some point
handle this situation differently.
^ permalink raw reply
* RE: [PATCH NEXT 1/3] netxen: fix lro buffer allocation
From: Dhananjay Phadke @ 2009-09-04 3:24 UTC (permalink / raw)
To: David Miller; +Cc: davem@davemloft.com, netdev@vger.kernel.org
In-Reply-To: <20090903.201537.26653675.davem@davemloft.net>
> But if the page allocator can't satisfy allocation requests
> it doesn't matter how many microseconds you're saving here.
>
> I think you're priorities are backwards.
Ok whatever. Whether I request 9k or 12k, page allocator
is digging 16k chunks.
When there's enough memory, every cycle saved is important
for firmware. I would love to enable fragmented rx, if it's
not affecting throughput.
-Dhananjay
^ permalink raw reply
* Re: [net-next PATCH 00/11] enic: updates
From: David Miller @ 2009-09-04 3:23 UTC (permalink / raw)
To: scofeldm; +Cc: netdev
In-Reply-To: <20090904030046.5047.46509.stgit@palito_client100.nuovasystems.com>
From: Scott Feldman <scofeldm@cisco.com>
Date: Thu, 03 Sep 2009 20:01:43 -0700
> The following series implements updates to the enic netdev driver for
> Cisco's 10G Ethernet NIC:
>
> 01 enic: add support for multiple BARs
> 02 enic: workaround A0 erratum
> 03 enic: bug fix: split TSO fragments larger than 16K into
> multiple descs
> 04 enic: use netdev_alloc_skb
> 05 enic: bug fix: protect fw call i/f with spinlock
> 06 enic: bug fix: included MAC drops in rx_dropped netstat
> 07 enic: provision for multiple Rx/Tx queues; prepare for RSS support
> 08 enic: bug fix: enable VLAN filtering
> 09 enic: changes to driver/firmware interface
> 10 enic: bug fix: check for zero port MTU before posting warning
> 11 enic: organize device initialization/deinit into separate functions
>
> Please apply.
>
> Signed-off-by: Scott Feldman <scofeldm@cisco.com>
Looks good, all aplied, thanks!
^ permalink raw reply
* Re: [PATCH NEXT 1/3] netxen: fix lro buffer allocation
From: David Miller @ 2009-09-04 3:15 UTC (permalink / raw)
To: dhananjay.phadke; +Cc: davem, netdev
In-Reply-To: <7608421F3572AB4292BB2532AE89D565865FA8A556@AVEXMB1.qlogic.org>
From: Dhananjay Phadke <dhananjay.phadke@qlogic.com>
Date: Thu, 3 Sep 2009 20:14:01 -0700
>
>
>> Applied. But allocating such huge linear buffers is asking for
>> guarenteed trouble. Can't you split them up into page sized chunks
>> with this chip?
>
> "chained" LRO is not enabled by firmware. Contiguous LRO requires
> fewer commands (internal) from firmware to DMA engines.
But if the page allocator can't satisfy allocation requests
it doesn't matter how many microseconds you're saving here.
I think you're priorities are backwards.
^ permalink raw reply
* RE: [PATCH NEXT 1/3] netxen: fix lro buffer allocation
From: Dhananjay Phadke @ 2009-09-04 3:14 UTC (permalink / raw)
To: David Miller; +Cc: davem@davemloft.com, netdev@vger.kernel.org
In-Reply-To: <20090903.200615.220020629.davem@davemloft.net>
> Applied. But allocating such huge linear buffers is asking for
> guarenteed trouble. Can't you split them up into page sized chunks
> with this chip?
"chained" LRO is not enabled by firmware. Contiguous LRO requires
fewer commands (internal) from firmware to DMA engines.
-Dhananjay
^ permalink raw reply
* [net-next PATCH 03/11] enic: bug fix: split TSO fragments larger than 16K into multiple descs
From: Scott Feldman @ 2009-09-04 3:02 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20090904030046.5047.46509.stgit@palito_client100.nuovasystems.com>
enic: bug fix: split TSO fragments larger than 16K into multiple descs
enic WQ desc supports a maximum 16K buf size, so split any send fragments
larger than 16K into several descs.
Signed-off-by: Scott Feldman <scofeldm@cisco.com>
---
drivers/net/enic/enic_main.c | 87 +++++++++++++++++++++++++++++++++---------
1 files changed, 69 insertions(+), 18 deletions(-)
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 3d7838d..a9e9be1 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -44,10 +44,15 @@
#include "enic.h"
#define ENIC_NOTIFY_TIMER_PERIOD (2 * HZ)
+#define WQ_ENET_MAX_DESC_LEN (1 << WQ_ENET_LEN_BITS)
+#define MAX_TSO (1 << 16)
+#define ENIC_DESC_MAX_SPLITS (MAX_TSO / WQ_ENET_MAX_DESC_LEN + 1)
+
+#define PCI_DEVICE_ID_CISCO_VIC_ENET 0x0043 /* ethernet vnic */
/* Supported devices */
static struct pci_device_id enic_id_table[] = {
- { PCI_VDEVICE(CISCO, 0x0043) },
+ { PCI_VDEVICE(CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET) },
{ 0, } /* end of table */
};
@@ -310,7 +315,8 @@ static int enic_wq_service(struct vnic_dev *vdev, struct cq_desc *cq_desc,
opaque);
if (netif_queue_stopped(enic->netdev) &&
- vnic_wq_desc_avail(&enic->wq[q_number]) >= MAX_SKB_FRAGS + 1)
+ vnic_wq_desc_avail(&enic->wq[q_number]) >=
+ (MAX_SKB_FRAGS + ENIC_DESC_MAX_SPLITS))
netif_wake_queue(enic->netdev);
spin_unlock(&enic->wq_lock[q_number]);
@@ -525,7 +531,11 @@ static inline void enic_queue_wq_skb_vlan(struct enic *enic,
unsigned int len_left = skb->len - head_len;
int eop = (len_left == 0);
- /* Queue the main skb fragment */
+ /* Queue the main skb fragment. The fragments are no larger
+ * than max MTU(9000)+ETH_HDR_LEN(14) bytes, which is less
+ * than WQ_ENET_MAX_DESC_LEN length. So only one descriptor
+ * per fragment is queued.
+ */
enic_queue_wq_desc(wq, skb,
pci_map_single(enic->pdev, skb->data,
head_len, PCI_DMA_TODEVICE),
@@ -547,7 +557,11 @@ static inline void enic_queue_wq_skb_csum_l4(struct enic *enic,
unsigned int csum_offset = hdr_len + skb->csum_offset;
int eop = (len_left == 0);
- /* Queue the main skb fragment */
+ /* Queue the main skb fragment. The fragments are no larger
+ * than max MTU(9000)+ETH_HDR_LEN(14) bytes, which is less
+ * than WQ_ENET_MAX_DESC_LEN length. So only one descriptor
+ * per fragment is queued.
+ */
enic_queue_wq_desc_csum_l4(wq, skb,
pci_map_single(enic->pdev, skb->data,
head_len, PCI_DMA_TODEVICE),
@@ -565,10 +579,14 @@ static inline void enic_queue_wq_skb_tso(struct enic *enic,
struct vnic_wq *wq, struct sk_buff *skb, unsigned int mss,
int vlan_tag_insert, unsigned int vlan_tag)
{
- unsigned int head_len = skb_headlen(skb);
- unsigned int len_left = skb->len - head_len;
+ unsigned int frag_len_left = skb_headlen(skb);
+ unsigned int len_left = skb->len - frag_len_left;
unsigned int hdr_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
int eop = (len_left == 0);
+ unsigned int len;
+ dma_addr_t dma_addr;
+ unsigned int offset = 0;
+ skb_frag_t *frag;
/* Preload TCP csum field with IP pseudo hdr calculated
* with IP length set to zero. HW will later add in length
@@ -584,17 +602,49 @@ static inline void enic_queue_wq_skb_tso(struct enic *enic,
&ipv6_hdr(skb)->daddr, 0, IPPROTO_TCP, 0);
}
- /* Queue the main skb fragment */
- enic_queue_wq_desc_tso(wq, skb,
- pci_map_single(enic->pdev, skb->data,
- head_len, PCI_DMA_TODEVICE),
- head_len,
- mss, hdr_len,
- vlan_tag_insert, vlan_tag,
- eop);
+ /* Queue WQ_ENET_MAX_DESC_LEN length descriptors
+ * for the main skb fragment
+ */
+ while (frag_len_left) {
+ len = min(frag_len_left, (unsigned int)WQ_ENET_MAX_DESC_LEN);
+ dma_addr = pci_map_single(enic->pdev, skb->data + offset,
+ len, PCI_DMA_TODEVICE);
+ enic_queue_wq_desc_tso(wq, skb,
+ dma_addr,
+ len,
+ mss, hdr_len,
+ vlan_tag_insert, vlan_tag,
+ eop && (len == frag_len_left));
+ frag_len_left -= len;
+ offset += len;
+ }
- if (!eop)
- enic_queue_wq_skb_cont(enic, wq, skb, len_left);
+ if (eop)
+ return;
+
+ /* Queue WQ_ENET_MAX_DESC_LEN length descriptors
+ * for additional data fragments
+ */
+ for (frag = skb_shinfo(skb)->frags; len_left; frag++) {
+ len_left -= frag->size;
+ frag_len_left = frag->size;
+ offset = frag->page_offset;
+
+ while (frag_len_left) {
+ len = min(frag_len_left,
+ (unsigned int)WQ_ENET_MAX_DESC_LEN);
+ dma_addr = pci_map_page(enic->pdev, frag->page,
+ offset, len,
+ PCI_DMA_TODEVICE);
+ enic_queue_wq_desc_cont(wq, skb,
+ dma_addr,
+ len,
+ (len_left == 0) &&
+ (len == frag_len_left)); /* EOP? */
+ frag_len_left -= len;
+ offset += len;
+ }
+ }
}
static inline void enic_queue_wq_skb(struct enic *enic,
@@ -647,7 +697,8 @@ static int enic_hard_start_xmit(struct sk_buff *skb, struct net_device *netdev)
spin_lock_irqsave(&enic->wq_lock[0], flags);
- if (vnic_wq_desc_avail(wq) < skb_shinfo(skb)->nr_frags + 1) {
+ if (vnic_wq_desc_avail(wq) <
+ skb_shinfo(skb)->nr_frags + ENIC_DESC_MAX_SPLITS) {
netif_stop_queue(netdev);
/* This is a hard error, log it */
printk(KERN_ERR PFX "%s: BUG! Tx ring full when "
@@ -658,7 +709,7 @@ static int enic_hard_start_xmit(struct sk_buff *skb, struct net_device *netdev)
enic_queue_wq_skb(enic, wq, skb);
- if (vnic_wq_desc_avail(wq) < MAX_SKB_FRAGS + 1)
+ if (vnic_wq_desc_avail(wq) < MAX_SKB_FRAGS + ENIC_DESC_MAX_SPLITS)
netif_stop_queue(netdev);
spin_unlock_irqrestore(&enic->wq_lock[0], flags);
^ permalink raw reply related
* [net-next PATCH 04/11] enic: use netdev_alloc_skb
From: Scott Feldman @ 2009-09-04 3:02 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20090904030046.5047.46509.stgit@palito_client100.nuovasystems.com>
enic: use netdev_alloc_skb
Use netdev_alloc_skb rather than dev_alloc_skb
Signed-off-by: Scott Feldman <scofeldm@cisco.com>
---
drivers/net/enic/enic_main.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index a9e9be1..d77119a 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -868,11 +868,12 @@ static void enic_free_rq_buf(struct vnic_rq *rq, struct vnic_rq_buf *buf)
dev_kfree_skb_any(buf->os_buf);
}
-static inline struct sk_buff *enic_rq_alloc_skb(unsigned int size)
+static inline struct sk_buff *enic_rq_alloc_skb(struct net_device *netdev,
+ unsigned int size)
{
struct sk_buff *skb;
- skb = dev_alloc_skb(size + NET_IP_ALIGN);
+ skb = netdev_alloc_skb(netdev, size + NET_IP_ALIGN);
if (skb)
skb_reserve(skb, NET_IP_ALIGN);
@@ -883,12 +884,13 @@ static inline struct sk_buff *enic_rq_alloc_skb(unsigned int size)
static int enic_rq_alloc_buf(struct vnic_rq *rq)
{
struct enic *enic = vnic_dev_priv(rq->vdev);
+ struct net_device *netdev = enic->netdev;
struct sk_buff *skb;
- unsigned int len = enic->netdev->mtu + ETH_HLEN;
+ unsigned int len = netdev->mtu + ETH_HLEN;
unsigned int os_buf_index = 0;
dma_addr_t dma_addr;
- skb = enic_rq_alloc_skb(len);
+ skb = enic_rq_alloc_skb(netdev, len);
if (!skb)
return -ENOMEM;
^ permalink raw reply related
* Re: [PATCH net-next-2.6] vlan: adds drops accounting
From: David Miller @ 2009-09-04 3:11 UTC (permalink / raw)
To: eric.dumazet; +Cc: kaber, netdev
In-Reply-To: <4A9F9CD4.7040408@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 03 Sep 2009 12:39:16 +0200
> Its hard to tell if vlans are dropping frames, since
> every frame given to vlan_???_start_xmit() functions
> is accounted as fully transmitted by lower device.
>
> We can test dev_queue_xmit() return values to
> properly account for dropped frames.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
But, how inappropriate would it be to keep doing the accounting
but pass the status back to the caller? Or will that screw up
the qdisc running engine?
^ permalink raw reply
* Re: [PATCH net-next-2.6] macvlan: add multiqueue capability
From: David Miller @ 2009-09-04 3:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: kaber, netdev
In-Reply-To: <4A9F9661.7020301@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 03 Sep 2009 12:11:45 +0200
> macvlan devices are currently not multi-queue capable.
>
> We can do that defining rtnl_link_ops method,
> get_tx_queues(), called from rtnl_create_link()
>
> This new method gets num_tx_queues/real_num_tx_queues
> from lower device.
>
> macvlan_get_tx_queues() is a copy of vlan_get_tx_queues().
>
> Because macvlan_start_xmit() has to update netdev_queue
> stats only (and not dev->stats), I chose to change
> tx_errors/tx_aborted_errors accounting to tx_dropped,
> since netdev_queue structure doesnt define tx_errors /
> tx_aborted_errors.
>
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sky2: only enable Vaux if capable of wakeup
From: David Miller @ 2009-09-04 3:10 UTC (permalink / raw)
To: shemminger; +Cc: rene.mayrhofer, mikem, netdev, leitner
In-Reply-To: <20090903091625.2e6aff91@nehalam>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Thu, 3 Sep 2009 09:16:25 -0700
> While perusing vendor driver, I saw that it did not enable the Vaux
> power unless device was able to wake from lan for D3cold.
> This might help for Rene's power issue.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] netdev: Convert MDIO ioctl implementation to use struct mii_ioctl_data
From: David Miller @ 2009-09-04 3:10 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1252010477.2781.20.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 03 Sep 2009 21:41:17 +0100
> A few drivers still access the arguments to MDIO ioctls as an array of
> u16. Convert them to use struct mii_ioctl_data.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] netdev: Remove redundant checks for CAP_NET_ADMIN in MDIO implementations
From: David Miller @ 2009-09-04 3:10 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1252010383.2781.17.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 03 Sep 2009 21:39:43 +0100
> dev_ioctl() already checks capable(CAP_NET_ADMIN) before calling the
> driver's implementation of MDIO ioctls.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Man, it wasn't fun validating the cases where you removed the
check function-wide for a ->ndo_dev_ioctl() implementation. :-/
Applied...
^ permalink raw reply
* Re: [PATCH 1/3] netdev: Remove SIOCDEVPRIVATE aliases for MDIO ioctls
From: David Miller @ 2009-09-04 3:09 UTC (permalink / raw)
To: bhutchings; +Cc: netdev
In-Reply-To: <1252010313.2781.14.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 03 Sep 2009 21:38:33 +0100
> The standard MDIO ioctl numbers are well-established and these should
> no longer be needed.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 3/3] ixgbe: Add support for using FCoE DDP in 82599 as FCoE targets
From: David Miller @ 2009-09-04 3:09 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, yi.zou
In-Reply-To: <20090904005630.14869.67340.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 03 Sep 2009 17:56:31 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> The FCoE DDP in 82599 can be used for both FCoE initiator as well as FCoE
> target, depending on the indication of the exchange being the responder or
> originator in the F_CTL (frame control) field in the encapsulated Fiber
> Channel frame header (T10 Spec., FC-FS). For the initiator, OX_ID is used
> for FCoE DDP, where for the target RX_ID is used for FCoE DDP.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 2/3] ixgbe: Distribute transmission of FCoE traffic in 82599
From: David Miller @ 2009-09-04 3:09 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, yi.zou
In-Reply-To: <20090904005609.14869.89202.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 03 Sep 2009 17:56:10 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> This adds a simple selection of a FCoE tx queue based on the current cpu id to
> distribute transmission of FCoE traffic evenly among multiple FCoE transmit
> queues.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
Does it matter that arbitrary programs or other stacks could transmit
ETH_P_FCOE traffic as well? Would that interfere with how this offload
hardware works now that you're directing all ETH_P_FCOE traffic to
FCOE rings?
^ permalink raw reply
* Re: [net-next PATCH 1/3] ixgbe: Add support for multiple Tx queues for FCoE in 82599
From: David Miller @ 2009-09-04 3:08 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, yi.zou
In-Reply-To: <20090904005549.14869.66878.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 03 Sep 2009 17:55:50 -0700
> From: Yi Zou <yi.zou@intel.com>
>
> This patch adds support for multiple transmit queues to the Fiber Channel
> over Ethernet (FCoE) feature found in 82599. Currently, FCoE has multiple
> Rx queues available, along with a redirection table, that helps distribute
> the I/O load across multiple CPUs based on the FC exchange ID. To make
> this the most effective, we need to provide the same layout of transmit
> queues to match receive.
>
> Particularly, when Data Center Bridging (DCB) is enabled, the designated
> traffic class for FCoE can have dedicated queues for just FCoE traffic,
> while not affecting any other type of traffic flow.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
So does this eat into the TX queues available to non-FCOE traffic
or is this a shared setup?
^ permalink raw reply
* Re: [net-next PATCH 3/3] igb: set vf rlpml wasn't taking vlan tag into account
From: David Miller @ 2009-09-04 3:07 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20090904004932.14537.49991.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 03 Sep 2009 17:49:33 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This patch updates things so that vlan tags are taken into account when
> setting the receive large packet maximum length. This allows the VF driver
> to correctly receive full sized frames when vlans are enabled.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 2/3] igb: only disable/enable interrupt bits for igb physical function
From: David Miller @ 2009-09-04 3:07 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20090904004914.14537.67180.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 03 Sep 2009 17:49:15 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> The igb_irq_disable/enable calls were causing virtual functions associated
> with the igb physical function to have their interrupts disabled. In order
> to prevent this from occuring we should only clear/set the bits related to
> the physical function.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 1/3] igb: add support for set_rx_mode netdevice operation
From: David Miller @ 2009-09-04 3:07 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20090904004828.14537.72187.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 03 Sep 2009 17:48:56 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This patch adds support for the set_rx_mode netdevice operation so that igb
> can better support multiple unicast addresses.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH NEXT 3/3] netxen: fix infinite loop on dma mapping failure
From: David Miller @ 2009-09-04 3:07 UTC (permalink / raw)
To: dhananjay; +Cc: davem, netdev
In-Reply-To: <1252019455-30683-3-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Thu, 3 Sep 2009 16:10:55 -0700
> Fix a perpetual while() loop in unwinding partial
> mapped tx skb on dma mapping failure.
>
> Reported-by: "Juha Leppanen" <juha_motorsportcom@luukku.com>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Applied.
^ 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