* Re: [net-next 4/6] e1000: configure and read MDI settings
From: Brandeburg, Jesse @ 2012-07-21 1:17 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Jeff Kirsher, davem, netdev, gospo, sassmann, Tushar Dave
In-Reply-To: <1342826859.11373.123.camel@deadeye.wl.decadent.org.uk>
On Fri, 20 Jul 2012, Ben Hutchings wrote:
> Why don't you set ecmd->eth_tp_mdix_ctrl here?
>
> If you also leave it as 0, it's impossible for userland to tell whether
> the current mode was forced or automatically selected.
Thanks for the review, right now the get interface (and ethtool display)
doesn't support any way to report if the setting was forced or not. I
didn't think about changing the get because I didn't want to modify the
userland reporting (I also figured it was a simple interface right now,
and didn't need changing, and was focused on the _set_ which is the part
fixing the users' reported bugs.)
I think the patches as they currently stand are okay, do you agree? I
would be glad to submit a followon to implement the new "get" interface if
we can hash out the interface changes, but I see no reason to gate these
patches.
^ permalink raw reply
* Re: [PATCH 1/2] net: ethernet: davinci_emac: Remove unnecessary #include
From: Mark A. Greer @ 2012-07-21 1:16 UTC (permalink / raw)
To: netdev; +Cc: linux-omap, linux-arm-kernel, Sekhar Nori
In-Reply-To: <1342833161-3314-1-git-send-email-mgreer@animalcreek.com>
Sigh, please ignore this series. I'll resend with [0/2].
^ permalink raw reply
* [PATCH 2/2] net: ethernet: davinci_emac: add pm_runtime support
From: Mark A. Greer @ 2012-07-21 1:12 UTC (permalink / raw)
To: netdev
Cc: linux-omap, linux-arm-kernel, Mark A. Greer, Sekhar Nori,
Kevin Hilman
In-Reply-To: <1342833161-3314-1-git-send-email-mgreer@animalcreek.com>
From: "Mark A. Greer" <mgreer@animalcreek.com>
Add pm_runtime support to the TI Davinci EMAC driver.
CC: Sekhar Nori <nsekhar@ti.com>
CC: Kevin Hilman <khilman@ti.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
---
a) Sorry for the bad patch earlier.
b) Now applies on top of net-next.
c) This patch depends on a patch by Kevin Hilman that has been
accepted for 3.6 and is waiting in arm-soc/for-next:
ce9dcb8784611c50974d1c6b600c71f5c0a29308
(ARM: davinci: add runtime PM support for clock management)
drivers/net/ethernet/ti/davinci_emac.c | 43 +++++++++++++++++-----------------
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 1a9c43f..fce89a0 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -57,6 +57,7 @@
#include <linux/bitops.h>
#include <linux/io.h>
#include <linux/uaccess.h>
+#include <linux/pm_runtime.h>
#include <linux/davinci_emac.h>
#include <linux/of.h>
#include <linux/of_address.h>
@@ -353,10 +354,6 @@ struct emac_priv {
void (*int_disable) (void);
};
-/* clock frequency for EMAC */
-static struct clk *emac_clk;
-static unsigned long emac_bus_frequency;
-
/* EMAC TX Host Error description strings */
static char *emac_txhost_errcodes[16] = {
"No error", "SOP error", "Ownership bit not set in SOP buffer",
@@ -1540,6 +1537,8 @@ static int emac_dev_open(struct net_device *ndev)
int k = 0;
struct emac_priv *priv = netdev_priv(ndev);
+ pm_runtime_get(&priv->pdev->dev);
+
netif_carrier_off(ndev);
for (cnt = 0; cnt < ETH_ALEN; cnt++)
ndev->dev_addr[cnt] = priv->mac_addr[cnt];
@@ -1609,7 +1608,7 @@ static int emac_dev_open(struct net_device *ndev)
priv->phy_id);
ret = PTR_ERR(priv->phydev);
priv->phydev = NULL;
- return ret;
+ goto err;
}
priv->link = 0;
@@ -1650,7 +1649,11 @@ rollback:
res = platform_get_resource(priv->pdev, IORESOURCE_IRQ, k-1);
m = res->end;
}
- return -EBUSY;
+
+ ret = -EBUSY;
+err:
+ pm_runtime_put(&priv->pdev->dev);
+ return ret;
}
/**
@@ -1692,6 +1695,7 @@ static int emac_dev_stop(struct net_device *ndev)
if (netif_msg_drv(priv))
dev_notice(emac_dev, "DaVinci EMAC: %s stopped\n", ndev->name);
+ pm_runtime_put(&priv->pdev->dev);
return 0;
}
@@ -1856,6 +1860,9 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
struct emac_platform_data *pdata;
struct device *emac_dev;
struct cpdma_params dma_params;
+ struct clk *emac_clk;
+ unsigned long emac_bus_frequency;
+
/* obtain emac clock from kernel */
emac_clk = clk_get(&pdev->dev, NULL);
@@ -1864,12 +1871,14 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
return -EBUSY;
}
emac_bus_frequency = clk_get_rate(emac_clk);
+ clk_put(emac_clk);
+
/* TODO: Probe PHY here if possible */
ndev = alloc_etherdev(sizeof(struct emac_priv));
if (!ndev) {
rc = -ENOMEM;
- goto free_clk;
+ goto no_ndev;
}
platform_set_drvdata(pdev, ndev);
@@ -1985,15 +1994,13 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
SET_ETHTOOL_OPS(ndev, ðtool_ops);
netif_napi_add(ndev, &priv->napi, emac_poll, EMAC_POLL_WEIGHT);
- clk_enable(emac_clk);
-
/* register the network device */
SET_NETDEV_DEV(ndev, &pdev->dev);
rc = register_netdev(ndev);
if (rc) {
dev_err(&pdev->dev, "error in register_netdev\n");
rc = -ENODEV;
- goto netdev_reg_err;
+ goto no_irq_res;
}
@@ -2002,10 +2009,12 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
"(regs: %p, irq: %d)\n",
(void *)priv->emac_base_phys, ndev->irq);
}
+
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_resume(&pdev->dev);
+
return 0;
-netdev_reg_err:
- clk_disable(emac_clk);
no_irq_res:
if (priv->txchan)
cpdma_chan_destroy(priv->txchan);
@@ -2019,8 +2028,7 @@ no_dma:
probe_quit:
free_netdev(ndev);
-free_clk:
- clk_put(emac_clk);
+no_ndev:
return rc;
}
@@ -2054,9 +2062,6 @@ static int __devexit davinci_emac_remove(struct platform_device *pdev)
iounmap(priv->remap_addr);
free_netdev(ndev);
- clk_disable(emac_clk);
- clk_put(emac_clk);
-
return 0;
}
@@ -2068,8 +2073,6 @@ static int davinci_emac_suspend(struct device *dev)
if (netif_running(ndev))
emac_dev_stop(ndev);
- clk_disable(emac_clk);
-
return 0;
}
@@ -2078,8 +2081,6 @@ static int davinci_emac_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct net_device *ndev = platform_get_drvdata(pdev);
- clk_enable(emac_clk);
-
if (netif_running(ndev))
emac_dev_open(ndev);
--
1.7.11.2
^ permalink raw reply related
* [PATCH 1/2] net: ethernet: davinci_emac: Remove unnecessary #include
From: Mark A. Greer @ 2012-07-21 1:12 UTC (permalink / raw)
To: netdev; +Cc: linux-omap, linux-arm-kernel, Mark A. Greer, Sekhar Nori
From: "Mark A. Greer" <mgreer@animalcreek.com>
The '#include <mach/mux.h>' line in davinci_emac.c
causes a compile error because that header file
isn't found. It turns out that the #include isn't
needed because the driver isn't (and shoudn't be)
touching the mux anyway, so remove it.
CC: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
---
drivers/net/ethernet/ti/davinci_emac.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index b298ab0..1a9c43f 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -63,8 +63,6 @@
#include <linux/of_irq.h>
#include <linux/of_net.h>
-#include <mach/mux.h>
-
#include <asm/irq.h>
#include <asm/page.h>
--
1.7.11.2
^ permalink raw reply related
* Re: ibmveth bug?
From: Benjamin Herrenschmidt @ 2012-07-21 0:52 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: santil, anton, paulus, netdev, linux-kernel, Anton Blanchard
In-Reply-To: <20120720224112.GD19288@linux.vnet.ibm.com>
On Fri, 2012-07-20 at 15:41 -0700, Nishanth Aravamudan wrote:
> Ping on this ... we've tripped the same issue on a different system, it
> would appear. Would appreciate if anyone can provide answers to the
> questions below.
Well, I haven't hit it but your description makes sense. Why not use
dma_alloc_coherent though ? Rather than kmalloc followed by map ?
At least on power we give you page alignment for these, so the problem
is solved magically :-) Another option is GFP + dma_map_page which is
roughly equivalent.
If you think it's a waste of space based on the queue size, then just
add an extra pointer, I wouldn't bother with a cache for something only
allocated when the driver initializes.
Cheers,
Ben.
> Thanks,
> Nish
>
> On 15.05.2012 [10:01:41 -0700], Nishanth Aravamudan wrote:
> > Hi Santiago,
> >
> > Are you still working on ibmveth?
> >
> > I've found a very sporadic bug with ibmveth in some testing. PAPR
> > requires that:
> >
> > "Validate the Buffer Descriptor of the receive queue buffer (I/O
> > addresses for entire buffer length starting at the spec- ified I/O
> > address are translated by the RTCE table, length is a multiple of 16
> > bytes, and alignment is on a 16 byte boundary) else H_Parameter."
> >
> > but from what I can tell ibmveth.c is not enforcing this last condition:
> >
> > adapter->rx_queue.queue_addr =
> > kmalloc(adapter->rx_queue.queue_len, GFP_KERNEL);
> >
> > ...
> >
> > adapter->rx_queue.queue_dma = dma_map_single(dev,
> > adapter->rx_queue.queue_addr, adapter->rx_queue.queue_len,
> > DMA_BIDIRECTIONAL);
> >
> > ...
> >
> > rxq_desc.fields.address = adapter->rx_queue.queue_dma;
> >
> > ...
> >
> >
> > lpar_rc = ibmveth_register_logical_lan(adapter, rxq_desc,
> > mac_address);
> > netdev_err(netdev, "buffer TCE:0x%llx filter TCE:0x%llx rxq "
> > "desc:0x%llx MAC:0x%llx\n", adapter->buffer_list_dma,
> > adapter->filter_list_dma, rxq_desc.desc, mac_address);
> >
> > And I got on one install attempt:
> >
> > [ 39.978430] ibmveth 30000004: eth0: h_register_logical_lan failed with -4
> > [ 39.978449] ibmveth 30000004: eth0: buffer TCE:0x1000 filter TCE:0x10000 rxq desc:0x80006010000200a8 MAC:0x56754de8e904
> >
> > rxq desc, as you can see is not 16byte aligned. kmalloc() only
> > guarantees 8-byte alignment (as does gcc, I think). Initially, I thought
> > we could just overallocate the queue_addr and ALIGN() down, but then we
> > would need to save the original kmalloc pointer in a new struct member
> > per rx_queue.
> >
> > So a couple of questions:
> >
> > 1) Is my analysis accurate? :)
> >
> > 2) How gross would it be to save an extra pointer for every rx_queue?
> >
> > 3) Based upon 2), is it better to just go ahead and create our own
> > kmem_cache (which gets an alignment specified)?
> >
> > For 3), I started coding this, but couldn't find a clean place to
> > allocate the kmem_cache itself, as the size of each object depends on
> > the run-time characteristics (afaict), but needs to be specified at
> > cache creation time. Any insight you could provide would be great!
> >
> > Thanks,
> > Nish
> >
> > --
> > Nishanth Aravamudan <nacc@us.ibm.com>
> > IBM Linux Technology Center
>
^ permalink raw reply
* RE: New commands to configure IOV features
From: Rose, Gregory V @ 2012-07-21 0:52 UTC (permalink / raw)
To: Chris Friesen, Ben Hutchings
Cc: Don Dutile, David Miller, yuvalmin@broadcom.com,
netdev@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <5009ECDF.4090305@genband.com>
> -----Original Message-----
> From: Chris Friesen [mailto:chris.friesen@genband.com]
> Sent: Friday, July 20, 2012 4:42 PM
> To: Ben Hutchings
> Cc: Don Dutile; David Miller; yuvalmin@broadcom.com; Rose, Gregory V;
> netdev@vger.kernel.org; linux-pci@vger.kernel.org
> Subject: Re: New commands to configure IOV features
>
> On 07/20/2012 02:01 PM, Ben Hutchings wrote:
> > On Fri, 2012-07-20 at 13:29 -0600, Chris Friesen wrote:
>
> >> Once the device exists, then domain-specific APIs would be used to
> >> configure it the same way that they would configure a physical device.
> >
> > To an extent, but not entirely.
> >
> > Currently, the assigned MAC address and (optional) VLAN tag for each
> > networking VF are configured via the PF net device (though this is
> > done though the rtnetlink API rather than ethtool).
>
> I actually have a use-case where the guest needs to be able to modify the
> MAC addresses of network devices that are actually VFs.
>
> The guest is bonding the network devices together, so the bonding driver
> in the guest expects to be able to set all the slaves to the same MAC
> address.
>
> As I read the ixgbe driver, this should be possible as long as the host
> hasn't explicitly set the MAC address of the VF. Is that correct?
That is correct.
- Greg
Intel Corp.
LAN Access Division
^ permalink raw reply
* Re: [PATCHv3 0/6] tun zerocopy support
From: David Miller @ 2012-07-21 0:49 UTC (permalink / raw)
To: mst; +Cc: jasowang, eric.dumazet, netdev, linux-kernel, ebiederm
In-Reply-To: <cover.1342812067.git.mst@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Fri, 20 Jul 2012 22:23:03 +0300
> Same as with macvtap, I get single-percentage wins in CPU utilization
> on guest to external from this patchset, and a performance regression on
> guest to host, so more work is needed until this feature can move out of
> experimental status, but I think it's useful for some people already.
>
> Pls review and consider for 3.6.
It doesn't improve performance in one case, and hurts performance in
another.
You'll have to give me a more compelling argument than that. You've
just given me every reason not to include these patches in 3.6
^ permalink raw reply
* Re: [PATCH] net-next: minor cleanups for bonding documentation
From: Jay Vosburgh @ 2012-07-21 0:08 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev, Andy Gospodarek
In-Reply-To: <20120720205137.84E3D290043B@tardy>
Rick Jones <raj@tardy.cup.hp.com> wrote:
>From: Rick Jones <rick.jones2@hp.com>
>
>The section titled "Configuring Bonding for Maximum Throughput" is
>actually section twelve not thirteen, and there are a couple of words
>spelled incorrectly.
>
>Signed-off-by: Rick Jones <rick.jones2@hp.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: New commands to configure IOV features
From: Chris Friesen @ 2012-07-20 23:42 UTC (permalink / raw)
To: Ben Hutchings
Cc: Don Dutile, David Miller, yuvalmin, gregory.v.rose, netdev,
linux-pci
In-Reply-To: <1342814473.2678.65.camel@bwh-desktop.uk.solarflarecom.com>
On 07/20/2012 02:01 PM, Ben Hutchings wrote:
> On Fri, 2012-07-20 at 13:29 -0600, Chris Friesen wrote:
>> Once the device exists, then domain-specific APIs would be used to
>> configure it the same way that they would configure a physical device.
>
> To an extent, but not entirely.
>
> Currently, the assigned MAC address and (optional) VLAN tag for each
> networking VF are configured via the PF net device (though this is done
> though the rtnetlink API rather than ethtool).
I actually have a use-case where the guest needs to be able to modify
the MAC addresses of network devices that are actually VFs.
The guest is bonding the network devices together, so the bonding driver
in the guest expects to be able to set all the slaves to the same MAC
address.
As I read the ixgbe driver, this should be possible as long as the host
hasn't explicitly set the MAC address of the VF. Is that correct?
Chris
^ permalink raw reply
* Re: [PATCH] ipv4: show pmtu in route list
From: Julian Anastasov @ 2012-07-20 23:46 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120720.162215.2278959554536542562.davem@davemloft.net>
Hello,
On Fri, 20 Jul 2012, David Miller wrote:
> From: Julian Anastasov <ja@ssi.bg>
> Date: Sat, 21 Jul 2012 02:26:28 +0300 (EEST)
>
> > I'll try this weekend to reorganize the seqlock
> > usage in tcp_metrics.c and to provide method to feed
> > rt_fill_info with values from this cache.
>
> Wouldn't it be better to just export the TCP metrics via it's own
> file or netlink facility?
>
> They keying of the TCP metrics is completely different from how routes
> are key'd. So I see little value in creating the illusion that these
> two things live in the same keying domain.
>
> The routing cache will be completely gone and /proc/net/rt_cache will
> be an empty file.
OK, then I'll try it in this way. When I have some
plan I'll be back for comments before implementing it.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH] rtnl: Add #ifdef CONFIG_RPS around num_rx_queues reference
From: Mark A. Greer @ 2012-07-20 23:35 UTC (permalink / raw)
To: netdev; +Cc: davem, Mark A. Greer, Jiri Pirko
From: "Mark A. Greer" <mgreer@animalcreek.com>
Commit 76ff5cc91935c51fcf1a6a99ffa28b97a6e7a884
(rtnl: allow to specify number of rx and tx queues
on device creation) added a reference to the net_device
structure's 'num_rx_queues' member in
net/core/rtnetlink.c:rtnl_fill_ifinfo()
However, the definition for 'num_rx_queues' is surrounded
by an '#ifdef CONFIG_RPS' while the new reference to it is
not. This causes a compile error when CONFIG_RPS is not
defined.
Fix the compile error by surrounding the new reference to
'num_rx_queues' by an '#ifdef CONFIG_RPS'.
CC: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
---
The problem can be easily reproduced by compiling with
davinci_all_defconfig (ARCH=arm). I don't know this
area well enough to know whether that (and other)
defconfigs should have CONFIG_RPS enabled or not, or
whether there is some missing Kconfig logic to enable
it.
net/core/rtnetlink.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 5bb1ebc..334b930 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -892,7 +892,9 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
nla_put_u32(skb, IFLA_GROUP, dev->group) ||
nla_put_u32(skb, IFLA_PROMISCUITY, dev->promiscuity) ||
nla_put_u32(skb, IFLA_NUM_TX_QUEUES, dev->num_tx_queues) ||
+#ifdef CONFIG_RPS
nla_put_u32(skb, IFLA_NUM_RX_QUEUES, dev->num_rx_queues) ||
+#endif
(dev->ifindex != dev->iflink &&
nla_put_u32(skb, IFLA_LINK, dev->iflink)) ||
(dev->master &&
--
1.7.11.2
^ permalink raw reply related
* [PATCH RFT] net: Change niu_rbr_fill() to use unlikely() to check niu_rbr_add_page() return value
From: Shuah Khan @ 2012-07-20 23:34 UTC (permalink / raw)
To: davem, mcarlson, bhutchings, eric.dumazet, mchan; +Cc: netdev, LKML, shuahkhan
Change niu_rbr_fill() to use unlikely() to check niu_rbr_add_page() return
value to be consistent with the rest of the checks after niu_rbr_add_page()
calls in this file.
Signed-off-by: Shuah Khan <shuah.khan@hp.com>
---
drivers/net/ethernet/sun/niu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
index 60d5c03..c2a0fe3 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -3517,7 +3517,7 @@ static int niu_rbr_fill(struct niu *np, struct rx_ring_info *rp, gfp_t mask)
err = 0;
while (index < (rp->rbr_table_size - blocks_per_page)) {
err = niu_rbr_add_page(np, rp, mask, index);
- if (err)
+ if (unlikely(err))
break;
index += blocks_per_page;
--
1.7.9.5
^ permalink raw reply related
* Re: [net-next 4/6] e1000: configure and read MDI settings
From: Ben Hutchings @ 2012-07-20 23:27 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, Jesse Brandeburg, netdev, gospo, sassmann, Tushar Dave
In-Reply-To: <1342820631-19738-5-git-send-email-jeffrey.t.kirsher@intel.com>
On Fri, 2012-07-20 at 14:43 -0700, Jeff Kirsher wrote:
> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
>
> This is the implementation in e1000 to allow ethtool to force
> MDI state, allowing users to work around some improperly
> behaving switches.
>
> Current get_settings behavior slightly changes in that now when link is down
> get_settings will return the MDI state of the last link because get_settings
> needs to succeed to allow the set to work even when link is down.
>
> Forcing in this driver is for now only allowed when auto-neg is enabled.
>
> To use must have the matching version of ethtool app that supports
> this functionality.
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> CC: Tushar Dave <tushar.n.dave@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 34 ++++++++++++++++++++++
> drivers/net/ethernet/intel/e1000/e1000_main.c | 4 +++
> 2 files changed, 38 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
> index 3103f0b..1d96bda 100644
> --- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
> +++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
> @@ -174,6 +174,15 @@ static int e1000_get_settings(struct net_device *netdev,
>
> ecmd->autoneg = ((hw->media_type == e1000_media_type_fiber) ||
> hw->autoneg) ? AUTONEG_ENABLE : AUTONEG_DISABLE;
> +
> + /* MDI-X => 1; MDI => 0 */
> + if (hw->media_type == e1000_media_type_copper)
> + ecmd->eth_tp_mdix = (!!adapter->phy_info.mdix_mode ?
> + ETH_TP_MDI_X :
> + ETH_TP_MDI);
> + else
> + ecmd->eth_tp_mdix = ETH_TP_MDI_INVALID;
[...]
Why don't you set ecmd->eth_tp_mdix_ctrl here?
If you also leave it as 0, it's impossible for userland to tell whether
the current mode was forced or automatically selected.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] ipv4: show pmtu in route list
From: David Miller @ 2012-07-20 23:22 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1207210219470.1893@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Sat, 21 Jul 2012 02:26:28 +0300 (EEST)
> I'll try this weekend to reorganize the seqlock
> usage in tcp_metrics.c and to provide method to feed
> rt_fill_info with values from this cache.
Wouldn't it be better to just export the TCP metrics via it's own
file or netlink facility?
They keying of the TCP metrics is completely different from how routes
are key'd. So I see little value in creating the illusion that these
two things live in the same keying domain.
The routing cache will be completely gone and /proc/net/rt_cache will
be an empty file.
^ permalink raw reply
* Re: [PATCH] ipv4: show pmtu in route list
From: Julian Anastasov @ 2012-07-20 23:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120720.111620.1609537308761180.davem@davemloft.net>
Hello,
On Fri, 20 Jul 2012, David Miller wrote:
> From: Julian Anastasov <ja@ssi.bg>
> Date: Fri, 20 Jul 2012 12:02:08 +0300
>
> > Is this patch still useful if routing cache is removed?
>
> It is, since this function still gets used for rtnetlink route
> queries. So I'll apply this, thanks Julian!
>
> Which reminds me that we don't have way to inspect the new TCP metrics
> cache. Would someone like to work on that?
I'll try this weekend to reorganize the seqlock
usage in tcp_metrics.c and to provide method to feed
rt_fill_info with values from this cache.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH] forcedeth: spin_unlock_irq in interrupt handler fix
From: David Miller @ 2012-07-20 23:18 UTC (permalink / raw)
To: yefremov.denis
Cc: david.decotigny, edumazet, jpirko, ian.campbell, netdev,
linux-kernel
In-Reply-To: <1342821274-20623-1-git-send-email-yefremov.denis@gmail.com>
From: Denis Efremov <yefremov.denis@gmail.com>
Date: Sat, 21 Jul 2012 01:54:34 +0400
> The replacement of spin_lock_irq/spin_unlock_irq pair in interrupt
> handler by spin_lock_irqsave/spin_lock_irqrestore pair.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Denis Efremov <yefremov.denis@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [GIT net-next] Open vSwitch
From: David Miller @ 2012-07-20 23:17 UTC (permalink / raw)
To: jesse-l0M0P4e3n4LQT0dZR+AlfA
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1342823210-3308-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
From: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Date: Fri, 20 Jul 2012 15:26:43 -0700
> A few bug fixes and small enhancements for net-next/3.6.
>
> The following changes since commit bf32fecdc1851ad9ca960f56771b798d17c26cf1:
>
> openvswitch: Add length check when retrieving TCP flags. (2012-04-02 14:28:57 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jesse/openvswitch.git master
Pulled, thanks Jesse.
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: David Miller @ 2012-07-20 23:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <20120720.155412.1512575922394612084.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 20 Jul 2012 15:54:12 -0700 (PDT)
> From: David Miller <davem@davemloft.net>
> Date: Fri, 20 Jul 2012 15:50:21 -0700 (PDT)
>
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Sat, 21 Jul 2012 00:42:46 +0200
>>
>>> (Apparently we choke on neighbour entries count.
>>>
>>> entries = atomic_inc_return(&tbl->entries) - 1;
>>>
>>> We need a percpu_counter ? Or something is wrong ?
>>
>> What do you mean we choke on it? Does it exceed the thresholds
>> and we start garbage-collecting?
>>
>> That would indicate a leak, or we are creating new neigh entries when
>> we shouldn't be, ie. we're not comparing the keys in the hash table
>> entries correctly during the lookup in net/ipv4/ip_output.c
>
> I see the problem, we get the key wrong during neigh creation for
> loopback.
>
> I'll fix this, thanks.
This should do it:
====================
[PATCH] ipv4: Fix neigh lookup keying over loopback/point-to-point devices.
We were using a special key "0" for all loopback and point-to-point
device neigh lookups under ipv4, but we wouldn't use that special
key for the neigh creation.
So basically we'd make a new neigh at each and every lookup :-)
This special case to use only one neigh for these device types
is of dubious value, so just remove it entirely.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/arp.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/net/arp.h b/include/net/arp.h
index 4617d98..7f7df93 100644
--- a/include/net/arp.h
+++ b/include/net/arp.h
@@ -21,9 +21,6 @@ static inline struct neighbour *__ipv4_neigh_lookup_noref(struct net_device *dev
struct neighbour *n;
u32 hash_val;
- if (dev->flags & (IFF_LOOPBACK | IFF_POINTOPOINT))
- key = 0;
-
hash_val = arp_hashfn(key, dev, nht->hash_rnd[0]) >> (32 - nht->hash_shift);
for (n = rcu_dereference_bh(nht->hash_buckets[hash_val]);
n != NULL;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: David Miller @ 2012-07-20 22:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <20120720.155021.1919200619716435427.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 20 Jul 2012 15:50:21 -0700 (PDT)
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sat, 21 Jul 2012 00:42:46 +0200
>
>> (Apparently we choke on neighbour entries count.
>>
>> entries = atomic_inc_return(&tbl->entries) - 1;
>>
>> We need a percpu_counter ? Or something is wrong ?
>
> What do you mean we choke on it? Does it exceed the thresholds
> and we start garbage-collecting?
>
> That would indicate a leak, or we are creating new neigh entries when
> we shouldn't be, ie. we're not comparing the keys in the hash table
> entries correctly during the lookup in net/ipv4/ip_output.c
I see the problem, we get the key wrong during neigh creation for
loopback.
I'll fix this, thanks.
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: David Miller @ 2012-07-20 22:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1342824166.2626.8112.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 21 Jul 2012 00:42:46 +0200
> (Apparently we choke on neighbour entries count.
>
> entries = atomic_inc_return(&tbl->entries) - 1;
>
> We need a percpu_counter ? Or something is wrong ?
What do you mean we choke on it? Does it exceed the thresholds
and we start garbage-collecting?
That would indicate a leak, or we are creating new neigh entries when
we shouldn't be, ie. we're not comparing the keys in the hash table
entries correctly during the lookup in net/ipv4/ip_output.c
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Eric Dumazet @ 2012-07-20 22:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1342821959.2626.8052.camel@edumazet-glaptop>
On Sat, 2012-07-21 at 00:06 +0200, Eric Dumazet wrote:
> Hmm, ok, please give me few hours to make some tests ;)
>
It seems we have a big regression somewhere with net-next,
but it is already there...
(Apparently we choke on neighbour entries count.
entries = atomic_inc_return(&tbl->entries) - 1;
We need a percpu_counter ? Or something is wrong ?
We also choke on write_lock_bh(&tbl->lock); (__write_lock_failed())
in __neigh_create()
current 'linux' tree :
tbench 24 -t 60
Operation Count AvgLat MaxLat
----------------------------------------
NTCreateX 8433514 0.023 1.566
Close 6195255 0.023 1.450
Rename 357080 0.022 1.457
Unlink 1702925 0.023 1.409
Deltree 240 0.000 0.001
Mkdir 120 0.024 0.032
Qpathinfo 7643560 0.023 1.565
Qfileinfo 1340393 0.023 1.566
Qfsinfo 1401593 0.023 1.425
Sfileinfo 686932 0.023 0.237
Find 2955412 0.023 1.566
WriteX 4209695 0.043 1.468
ReadX 13218668 0.029 1.614
LockX 27458 0.024 0.059
UnlockX 27458 0.024 0.056
Flush 591126 0.023 0.317
Throughput 4418.83 MB/sec 24 clients 24 procs max_latency=2.433 ms
net-next tree with your 16 patches :
Operation Count AvgLat MaxLat
----------------------------------------
NTCreateX 6545220 0.031 14.433
Close 4808070 0.031 14.105
Rename 277171 0.030 0.737
Unlink 1321711 0.031 2.370
Deltree 172 0.000 0.001
Mkdir 86 0.033 0.134
Qpathinfo 5932577 0.031 11.607
Qfileinfo 1039922 0.031 6.075
Qfsinfo 1087803 0.031 12.178
Sfileinfo 533226 0.031 0.993
Find 2293696 0.031 11.059
WriteX 3264634 0.054 19.164
ReadX 10260208 0.038 11.857
LockX 21319 0.032 0.168
UnlockX 21319 0.032 0.162
Flush 458724 0.032 1.774
Throughput 3425.42 MB/sec 24 clients 24 procs max_latency=19.174 ms
perf output for linux tree :
Samples: 6M of event 'cycles', Event count (approx.): 4966119889380
4,18% tbench tbench [.] 0x0000000000001f49
4,09% tbench libc-2.15.so [.] 0x000000000003cb08
3,10% tbench_srv [kernel.kallsyms] [k] copy_user_generic_string
2,05% tbench_srv [kernel.kallsyms] [k] ipt_do_table
2,04% tbench [kernel.kallsyms] [k] ipt_do_table
1,48% tbench [kernel.kallsyms] [k] copy_user_generic_string
1,43% tbench_srv [kernel.kallsyms] [k] tcp_ack
1,08% tbench_srv [kernel.kallsyms] [k] tcp_recvmsg
1,06% tbench [kernel.kallsyms] [k] nf_iterate
1,00% tbench_srv [kernel.kallsyms] [k] nf_iterate
0,94% tbench_srv [nf_conntrack] [k] tcp_packet
0,94% tbench [nf_conntrack] [k] tcp_packet
0,90% tbench_srv [kernel.kallsyms] [k] __schedule
0,87% tbench [kernel.kallsyms] [k] __schedule
0,87% tbench_srv [kernel.kallsyms] [k] _raw_spin_lock_bh
0,85% tbench_srv [kernel.kallsyms] [k] tcp_sendmsg
0,80% tbench [kernel.kallsyms] [k] __switch_to
0,79% tbench [kernel.kallsyms] [k] _raw_spin_lock_bh
0,77% tbench libc-2.15.so [.] vfprintf
0,76% tbench [kernel.kallsyms] [k] tcp_sendmsg
0,74% tbench [kernel.kallsyms] [k] select_task_rq_fair
0,72% tbench_srv tbench_srv [.] 0x0000000000001840
0,70% tbench_srv libc-2.15.so [.] recv
0,65% tbench_srv [kernel.kallsyms] [k] tcp_rcv_established
0,65% tbench [kernel.kallsyms] [k] tcp_transmit_skb
0,64% tbench [vdso] [.] 0x00007fffd93459e8
0,63% tbench_srv [kernel.kallsyms] [k] tcp_transmit_skb
0,63% tbench [kernel.kallsyms] [k] tcp_recvmsg
0,55% tbench_srv [nf_conntrack] [k] nf_conntrack_in
perf for net-next tree :
Samples: 6M of event 'cycles', Event count (approx.): 4685309724658
3,42% tbench tbench [.] 0x00000000000035ab
3,32% tbench libc-2.15.so [.] 0x00000000000913f0
2,52% tbench_srv [kernel.kallsyms] [k] copy_user_generic_string
1,75% tbench [kernel.kallsyms] [k] ipt_do_table
1,71% tbench_srv [kernel.kallsyms] [k] ipt_do_table
1,31% tbench [kernel.kallsyms] [k] __neigh_create
1,25% tbench_srv [kernel.kallsyms] [k] __neigh_create
1,23% tbench [kernel.kallsyms] [k] nf_iterate
1,19% tbench [kernel.kallsyms] [k] copy_user_generic_string
1,19% tbench_srv [kernel.kallsyms] [k] nf_iterate
1,02% tbench_srv [kernel.kallsyms] [k] tcp_ack
0,96% tbench_srv [kernel.kallsyms] [k] tcp_recvmsg
0,88% tbench_srv [kernel.kallsyms] [k] __write_lock_failed
0,88% tbench [kernel.kallsyms] [k] __write_lock_failed
0,82% tbench [kernel.kallsyms] [k] __schedule
0,77% tbench_srv [kernel.kallsyms] [k] tcp_sendmsg
0,76% tbench_srv [kernel.kallsyms] [k] __schedule
0,76% tbench [nf_conntrack] [k] tcp_packet
0,74% tbench_srv [nf_conntrack] [k] tcp_packet
0,74% tbench [kernel.kallsyms] [k] __switch_to
0,71% tbench_srv [kernel.kallsyms] [k] _raw_spin_lock_bh
0,68% tbench [kernel.kallsyms] [k] tcp_sendmsg
0,66% tbench [kernel.kallsyms] [k] _raw_spin_lock_bh
0,63% tbench [kernel.kallsyms] [k] ip_finish_output
0,63% tbench [kernel.kallsyms] [k] tcp_recvmsg
0,61% tbench_srv [kernel.kallsyms] [k] ip_finish_output
0,61% tbench [vdso] [.] 0x00007fffb57ff8d1
0,60% tbench_srv libc-2.15.so [.] recv
0,59% tbench [kernel.kallsyms] [k] neigh_destroy
^ permalink raw reply
* Re: ibmveth bug?
From: Nishanth Aravamudan @ 2012-07-20 22:41 UTC (permalink / raw)
To: santil; +Cc: anton, benh, paulus, netdev, linux-kernel
In-Reply-To: <20120515170141.GA14272@linux.vnet.ibm.com>
Ping on this ... we've tripped the same issue on a different system, it
would appear. Would appreciate if anyone can provide answers to the
questions below.
Thanks,
Nish
On 15.05.2012 [10:01:41 -0700], Nishanth Aravamudan wrote:
> Hi Santiago,
>
> Are you still working on ibmveth?
>
> I've found a very sporadic bug with ibmveth in some testing. PAPR
> requires that:
>
> "Validate the Buffer Descriptor of the receive queue buffer (I/O
> addresses for entire buffer length starting at the spec- ified I/O
> address are translated by the RTCE table, length is a multiple of 16
> bytes, and alignment is on a 16 byte boundary) else H_Parameter."
>
> but from what I can tell ibmveth.c is not enforcing this last condition:
>
> adapter->rx_queue.queue_addr =
> kmalloc(adapter->rx_queue.queue_len, GFP_KERNEL);
>
> ...
>
> adapter->rx_queue.queue_dma = dma_map_single(dev,
> adapter->rx_queue.queue_addr, adapter->rx_queue.queue_len,
> DMA_BIDIRECTIONAL);
>
> ...
>
> rxq_desc.fields.address = adapter->rx_queue.queue_dma;
>
> ...
>
>
> lpar_rc = ibmveth_register_logical_lan(adapter, rxq_desc,
> mac_address);
> netdev_err(netdev, "buffer TCE:0x%llx filter TCE:0x%llx rxq "
> "desc:0x%llx MAC:0x%llx\n", adapter->buffer_list_dma,
> adapter->filter_list_dma, rxq_desc.desc, mac_address);
>
> And I got on one install attempt:
>
> [ 39.978430] ibmveth 30000004: eth0: h_register_logical_lan failed with -4
> [ 39.978449] ibmveth 30000004: eth0: buffer TCE:0x1000 filter TCE:0x10000 rxq desc:0x80006010000200a8 MAC:0x56754de8e904
>
> rxq desc, as you can see is not 16byte aligned. kmalloc() only
> guarantees 8-byte alignment (as does gcc, I think). Initially, I thought
> we could just overallocate the queue_addr and ALIGN() down, but then we
> would need to save the original kmalloc pointer in a new struct member
> per rx_queue.
>
> So a couple of questions:
>
> 1) Is my analysis accurate? :)
>
> 2) How gross would it be to save an extra pointer for every rx_queue?
>
> 3) Based upon 2), is it better to just go ahead and create our own
> kmem_cache (which gets an alignment specified)?
>
> For 3), I started coding this, but couldn't find a clean place to
> allocate the kmem_cache itself, as the size of each object depends on
> the run-time characteristics (afaict), but needs to be specified at
> cache creation time. Any insight you could provide would be great!
>
> Thanks,
> Nish
>
> --
> Nishanth Aravamudan <nacc@us.ibm.com>
> IBM Linux Technology Center
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* [PATCH net-next 7/7] openvswitch: Fix typo in documentation.
From: Jesse Gross @ 2012-07-20 22:26 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1342823210-3308-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
From: Leo Alterman <lalterman-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Leo Alterman <lalterman-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
Documentation/networking/openvswitch.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/networking/openvswitch.txt b/Documentation/networking/openvswitch.txt
index b8a048b..8fa2dd1 100644
--- a/Documentation/networking/openvswitch.txt
+++ b/Documentation/networking/openvswitch.txt
@@ -118,7 +118,7 @@ essentially like this, ignoring metadata:
Naively, to add VLAN support, it makes sense to add a new "vlan" flow
key attribute to contain the VLAN tag, then continue to decode the
encapsulated headers beyond the VLAN tag using the existing field
-definitions. With this change, an TCP packet in VLAN 10 would have a
+definitions. With this change, a TCP packet in VLAN 10 would have a
flow key much like this:
eth(...), vlan(vid=10, pcp=0), eth_type(0x0800), ip(proto=6, ...), tcp(...)
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next 6/7] openvswitch: Check gso_type for correct sk_buff in queue_gso_packets().
From: Jesse Gross @ 2012-07-20 22:26 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1342823210-3308-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
From: Ben Pfaff <blp-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
At the point where it was used, skb_shinfo(skb)->gso_type referred to a
post-GSO sk_buff. Thus, it would always be 0. We want to know the pre-GSO
gso_type, so we need to obtain it before segmenting.
Before this change, the kernel would pass inconsistent data to userspace:
packets for UDP fragments with nonzero offset would be passed along with
flow keys that indicate a zero offset (that is, the flow key for "later"
fragments claimed to be "first" fragments). This inconsistency tended
to confuse Open vSwitch userspace, causing it to log messages about
"failed to flow_del" the flows with "later" fragments.
Signed-off-by: Ben Pfaff <blp-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
net/openvswitch/datapath.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 670e630..29dbfcb 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -263,6 +263,7 @@ err:
static int queue_gso_packets(int dp_ifindex, struct sk_buff *skb,
const struct dp_upcall_info *upcall_info)
{
+ unsigned short gso_type = skb_shinfo(skb)->gso_type;
struct dp_upcall_info later_info;
struct sw_flow_key later_key;
struct sk_buff *segs, *nskb;
@@ -279,7 +280,7 @@ static int queue_gso_packets(int dp_ifindex, struct sk_buff *skb,
if (err)
break;
- if (skb == segs && skb_shinfo(skb)->gso_type & SKB_GSO_UDP) {
+ if (skb == segs && gso_type & SKB_GSO_UDP) {
/* The initial flow key extracted by ovs_flow_extract()
* in this case is for a first fragment, so we need to
* properly mark later fragments.
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next 5/7] openvswitch: Check currect return value from skb_gso_segment()
From: Jesse Gross @ 2012-07-20 22:26 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1342823210-3308-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
From: Pravin B Shelar <pshelar-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Fix return check typo.
Signed-off-by: Pravin B Shelar <pshelar-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
net/openvswitch/datapath.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index b512cb8..670e630 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -269,8 +269,8 @@ static int queue_gso_packets(int dp_ifindex, struct sk_buff *skb,
int err;
segs = skb_gso_segment(skb, NETIF_F_SG | NETIF_F_HW_CSUM);
- if (IS_ERR(skb))
- return PTR_ERR(skb);
+ if (IS_ERR(segs))
+ return PTR_ERR(segs);
/* Queue all of the segments. */
skb = segs;
--
1.7.9.5
^ permalink raw reply related
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