* Re: Warning: myri10ge/sky2/vxge/r8169/niu/bnx2/bnx2x/igb/e100e/cxgb3/mlx4/tg3/vxge : removal of PCI_CAP_ID_EXP
From: Jon Mason @ 2011-07-06 3:14 UTC (permalink / raw)
To: James Smart
Cc: nic_swsd, divy, e1000-devel, netdev, romieu, mcarlson, eilong,
yevgenyp, Richard Lary, gallatin, shemminger, davem@davemloft.net,
mchan
In-Reply-To: <BANLkTi=BCC3PO_LecW77ht+kBAAVD6=Kgw@mail.gmail.com>
On Fri, Jul 1, 2011 at 10:28 AM, Jon Mason <jdmason@kudzu.us> wrote:
> On Fri, Jul 1, 2011 at 9:49 AM, James Smart <james.smart@emulex.com> wrote:
>> All,
>>
>> I wanted to communicate a potential warning to those drivers that had a
>> patch submitted to replace config space searches of PCI_CAP_ID_EXP with
>> shorthand options such as is_pcie and pci_is_pcie().
>>
>> Testing with the lpfc driver and AER/EEH identified cases where the
>> short-hand search options would fail on PPC platforms. The only successful
>> option in all cases was the explicit search via PCI_CAP_ID_EXP. Therefore,
>> I recommend that this change not be accepted until the platform level issue
>> can be identified and corrected.
>
> pci_is_pcie checks for a PCI-E capability offset that was determined
> by calling pci_find_capability during the PCI bus walking. Based on
> your description above this should be functionally equivalent. If
> this is not safe, then the PCI bus walking code is most likely busted
> on EEH enabled PPC systems (and that is a BIG problem).
>
> I have e-mailed the PPC and PCI mailing lists to verify the issue.
Per Richard Lary's testing, this is not an issue with the latest kernel.
http://www.spinics.net/lists/linux-pci/msg11350.html
Thanks,
Jon
>
> Thanks,
> Jon
>
>
>>
>> -- james s
>>
>>
>>
>> On 6/30/2011 4:41 PM, James Smart wrote:
>>>
>>> Jon,
>>>
>>> I must NACK this patch to the lpfc driver and recommend that all other
>>> patches
>>> which replace pci_find_capability(pdef, PCI_CAP_ID_EXP) with
>>> "pci_is_pcie(pdev)" are NACK'd as well.
>>>
>>> The reason is due to an issue on PPC platforms whereby use of
>>> "pdev->is_pcie"
>>> and pci_is_pcie() will erroneously fail under some conditions, but
>>> explicit
>>> search for the capability struct via pci_find_capability() is always
>>> successful. I expect this to be due a shadowing of pci config space in
>>> the
>>> hal/platform that isn't sufficiently built up. We detected this issue
>>> while
>>> testing AER/EEH, and are functional only if the pci_find_capability()
>>> option
>>> is used.
>>>
>>> -- james s
>>>
>>>
>>>
>>> On 6/27/2011 1:39 PM, Jon Mason wrote:
>>>>
>>>> The PCIE capability offset is saved during PCI bus walking. It will
>>>> remove an unnecessary search in the PCI configuration space if this
>>>> value is referenced instead of reacquiring it. Also, pci_is_pcie is a
>>>> better way of determining if the device is PCIE or not (as it uses the
>>>> same saved PCIE capability offset).
>>>>
>>>> Signed-off-by: Jon Mason<jdmason@kudzu.us>
>>>> ---
>>>> drivers/scsi/lpfc/lpfc_init.c | 2 +-
>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/drivers/scsi/lpfc/lpfc_init.c
>>>> b/drivers/scsi/lpfc/lpfc_init.c
>>>> index 148b98d..9000ad0 100644
>>>> --- a/drivers/scsi/lpfc/lpfc_init.c
>>>> +++ b/drivers/scsi/lpfc/lpfc_init.c
>>>> @@ -3970,7 +3970,7 @@ lpfc_enable_pci_dev(struct lpfc_hba *phba)
>>>> pci_save_state(pdev);
>>>>
>>>> /* PCIe EEH recovery on powerpc platforms needs fundamental reset
>>>> */
>>>> - if (pci_find_capability(pdev, PCI_CAP_ID_EXP))
>>>> + if (pci_is_pcie(pdev))
>>>> pdev->needs_freset = 1;
>>>>
>>>> return 0;
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 0/2] AF_PACKET fanout support
From: Tom Herbert @ 2011-07-06 3:13 UTC (permalink / raw)
To: David Miller; +Cc: victor, netdev, willemb
In-Reply-To: <20110705.182041.1392492274453963565.davem@davemloft.net>
>> Also, another useful mode of steering would be to steer packets to a
>> socket which was recently processed by a thread running on the same
>> CPU; somewhat analogous to RFS (cc'ed WIllem Bruijn who is already
>> working on this I believe).
>
> This sounds like a good way to overload a local socket and prevent
> pushing the work to lesser used sockets on other cpus.
>
Sure, it you're not using RPS or RSS! These should already be
distributing the RX work amongst CPUs.
^ permalink raw reply
* linux-next: manual merge of the net tree with the wireless-current tree
From: Stephen Rothwell @ 2011-07-06 2:53 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Gustavo F. Padovan
Hi all,
Today's linux-next merge of the net tree got a conflict in
net/bluetooth/l2cap_core.c between commit 9fa7e4f76f36 ("Bluetooth: Fix
regression with incoming L2CAP connections") from the wireless-current
tree and commit 89bc500e41fc ("Bluetooth: Add state tracking to struct
l2cap_chan") from the net tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/bluetooth/l2cap_core.c
index ebff14c,9ec9c8c..0000000
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@@ -2323,8 -2530,7 +2530,8 @@@ static inline int l2cap_config_req(stru
sk = chan->sk;
- if ((bt_sk(sk)->defer_setup && sk->sk_state != BT_CONNECT2) ||
- (!bt_sk(sk)->defer_setup && sk->sk_state != BT_CONFIG)) {
- if (chan->state != BT_CONFIG) {
++ if ((bt_sk(sk)->defer_setup && chan->state != BT_CONNECT2) ||
++ (!bt_sk(sk)->defer_setup && chan->state != BT_CONFIG)) {
struct l2cap_cmd_rej rej;
rej.reason = cpu_to_le16(0x0002);
^ permalink raw reply
* Re: [PATCH v2 0/3] Add device tree probe support for imx fec driver
From: David Miller @ 2011-07-06 2:48 UTC (permalink / raw)
To: shawn.guo-QSEj5FYQhm4dnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
patches-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1309878839-25743-1-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
From: Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Date: Tue, 5 Jul 2011 23:13:56 +0800
> The first two patches are a little off topic. Patch #1 adds a helper
> function of_get_phy_mode into of_net, and #2 converts ibm_newemac net
> driver to use this helper function. Patch #3 is the actual one adding
> tree probe support for imx fec driver, with of_get_phy_mode being used.
>
> Changes since v1:
> * Address review comments given by Grant
> * Add patch #1 and #2
>
> Shawn Guo (3):
> dt/net: add helper function of_get_phy_mode
> net: ibm_newemac: convert it to use of_get_phy_mode
> net/fec: add device tree probe support
All applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: pull request: batman-adv 2011-07-05
From: David Miller @ 2011-07-06 2:46 UTC (permalink / raw)
To: lindner_marek-LWAfsSFWpa4
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1309873440-11704-1-git-send-email-lindner_marek-LWAfsSFWpa4@public.gmane.org>
From: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
Date: Tue, 5 Jul 2011 15:43:54 +0200
> The following changes since commit 43676ab590c3f8686fd047d34c3e33803eef71f0:
>
> batman-adv: improved gateway tq-based selection (2011-06-20 11:37:41 +0200)
>
> are available in the git repository at:
> git://git.open-mesh.org/linux-merge.git batman-adv/next
Pulled, thanks.
^ permalink raw reply
* [PATCH net-next v2] net: Add GSO to vlan_features initialization
From: Shan Wei @ 2011-07-06 2:09 UTC (permalink / raw)
To: David Miller, 单卫, netdev
Just add GSO to vlan_features initialization, and update comments.
When we set offload features, vlan_dev_fix_features() will do more check.
In vlan_dev_fix_features(), final features is decided by
features of real device and vlan_features of real device.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
---
v2: update changelog.
---
net/core/dev.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 4577e67..9ca1514 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5488,11 +5488,12 @@ int register_netdevice(struct net_device *dev)
dev->features |= NETIF_F_NOCACHE_COPY;
}
- /* Enable GRO and NETIF_F_HIGHDMA for vlans by default,
- * vlan_dev_init() will do the dev->features check, so these features
- * are enabled only if supported by underlying device.
+ /* Enable GSO, GRO and NETIF_F_HIGHDMA for vlans by default,
+ * vlan_dev_fix_features() will do the features check,
+ * so NETIF_F_HIGHDMA feature is enabled only if supported
+ * by underlying device.
*/
- dev->vlan_features |= (NETIF_F_GRO | NETIF_F_HIGHDMA);
+ dev->vlan_features |= (NETIF_F_SOFT_FEATURES | NETIF_F_HIGHDMA);
ret = call_netdevice_notifiers(NETDEV_POST_INIT, dev);
ret = notifier_to_errno(ret);
--
1.7.4.1
^ permalink raw reply related
* [PATCH bug-fix v2] net: vlan: enable soft features regardless of underlying device
From: Shan Wei @ 2011-07-06 2:08 UTC (permalink / raw)
To: David Miller, 单卫, netdev
If gso/gro feature of underlying device is turned off，
then new created vlan device never can turn gso/gro on.
Although underlying device don't support TSO, we still
should use software segments for vlan device.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
---
v2: only update changelog and title.
---
net/8021q/vlan_dev.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 1c9aa8c..d8f45ba 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -588,9 +588,14 @@ static void vlan_dev_uninit(struct net_device *dev)
static u32 vlan_dev_fix_features(struct net_device *dev, u32 features)
{
struct net_device *real_dev = vlan_dev_info(dev)->real_dev;
+ u32 old_features = features;
features &= real_dev->features;
features &= real_dev->vlan_features;
+
+ if (old_features & NETIF_F_SOFT_FEATURES)
+ features |= old_features & NETIF_F_SOFT_FEATURES;
+
if (dev_ethtool_get_rx_csum(real_dev))
features |= NETIF_F_RXCSUM;
features |= NETIF_F_LLTX;
--
1.7.4.1
^ permalink raw reply related
* Re: [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP setup
From: David Miller @ 2011-07-06 1:40 UTC (permalink / raw)
To: herbert; +Cc: mike, netdev
In-Reply-To: <20110705235833.GA5599@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.hengli.com.au>
Date: Wed, 6 Jul 2011 07:58:33 +0800
> bridge: Always flood broadcast packets
>
> As is_multicast_ether_addr returns true on broadcast packets as
> well, we need to explicitly exclude broadcast packets so that
> they're always flooded. This wasn't an issue before as broadcast
> packets were considered to be an unregistered multicast group,
> which were always flooded. However, as we now only flood such
> packets to router ports, this is no longer acceptable.
>
> Reported-by: Michael Guntsche <mike@it-loops.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: [PATCH] vmxnet3: fix starving rx ring whenoc_skb kb fails
From: David Miller @ 2011-07-06 1:40 UTC (permalink / raw)
To: sbhatewara; +Cc: bhutchings, pv-drivers, netdev, scottjg
In-Reply-To: <alpine.LRH.2.00.1107051721230.32629@sbhatewara-dev1.eng.vmware.com>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Tue, 5 Jul 2011 17:34:05 -0700 (PDT)
>
> If the rx ring is completely empty, then the device may never fire an rx
> interrupt. Unfortunately, the rx interrupt is what triggers populating the
> rx ring with fresh buffers, so this will cause networking to lock up.
>
> This patch replenishes the skb in recv descriptor as soon as it is
> peeled off while processing rx completions. If the skb/buffer
> allocation fails, existing one is recycled and the packet in hand is
> dropped. This way none of the RX desc is ever left empty, thus avoiding
> starvation
>
> Signed-off-by: Scott J. Goldman <scottjg@vmware.com>
> Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
Applied.
^ permalink raw reply
* Re: [PATCH] usb: usbnet: suspend count gets lost when -EBUSY
From: David Miller @ 2011-07-06 1:40 UTC (permalink / raw)
To: C.Fries, qcf001; +Cc: netdev, stable
In-Reply-To: <CADuEq9BQX2BFBY3pF=CEEymfK4JPwMP7By+JZFdaLqxs+GhtJQ@mail.gmail.com>
From: Chris Fries <qcf001@motorola.com>
Date: Tue, 5 Jul 2011 20:35:05 -0500
> +++ b/drivers/net/usb/usbnet.c
> @@ -1451,6 +1451,7 @@ int usbnet_suspend (struct usb_interface *intf,
> pm_message_t message)
Your email client has mangled your patch, please read
"Documentation/email-clients.txt" on how to fix this.
Once you've fixed it, email the patch to yourself and
verify that you yourself can successfully apply the
patch you receive.
^ permalink raw reply
* Opportunity
From: M.L @ 2011-07-06 1:38 UTC (permalink / raw)
Hello I am contacting you with regards to a business transaction I want us to execute, it is in respect to a dormant account which belongs to my late client.
I believe we may be able to make good of this situation for ourselves. Please indicate your interest and I will give you more information.
Kind regards
M.L.
^ permalink raw reply
* [PATCH] usb: usbnet: suspend count gets lost when -EBUSY
From: Chris Fries @ 2011-07-06 1:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev, stable
When suspend is refused due to pending transmits, the
busy counter gets out of sync, and suspend will stop
working correctly.
Signed-off-by: Chris Fries <C.Fries@motorola.com>
---
drivers/net/usb/usbnet.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index cc95aad..9bcc3e3 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1451,6 +1451,7 @@ int usbnet_suspend (struct usb_interface *intf,
pm_message_t message)
/* don't autosuspend while transmitting */
if (dev->txq.qlen && (message.event & PM_EVENT_AUTO)) {
spin_unlock_irq(&dev->txq.lock);
+ dev->suspend_count--;
return -EBUSY;
} else {
set_bit(EVENT_DEV_ASLEEP, &dev->flags);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH net-next-2.6] net: sched: constify tcf_proto and tc_action
From: David Miller @ 2011-07-06 1:33 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <20110705.183234.1710750208514203200.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 05 Jul 2011 18:32:34 -0700 (PDT)
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 05 Jul 2011 18:36:47 +0200
>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Applied, thanks Eric.
Actually, I'm reverting:
net/sched/act_ipt.c:294:2: warning: initialization from incompatible pointer type [enabled by default]
net/sched/act_ipt.c:294:2: warning: (near initialization for ‘act_ipt_ops.act’) [enabled by default]
net/sched/act_csum.c:572:2: warning: initialization from incompatible pointer type [enabled by default]
net/sched/act_csum.c:572:2: warning: (near initialization for ‘act_csum_ops.act’) [enabled by default]
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: sched: constify tcf_proto and tc_action
From: David Miller @ 2011-07-06 1:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1309883807.2271.30.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 05 Jul 2011 18:36:47 +0200
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2011-07-05
From: David Miller @ 2011-07-06 1:29 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20110705204106.GG7540@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 5 Jul 2011 16:41:07 -0400
> Here is another big batch of changed intended for 3.1. This looks
> bigger than it is, as it also contains a wireless-2.6 pull to resolve
> some build conflicts.
>
> The most noteworth item is yet another rtlwifi-based driver (rtl8192de).
> There is also some HT-phy work for b43, plus the usual contributions
> from the ath9k and iwlwifi crews and a variety of other bits here and
> there.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH 0/2] AF_PACKET fanout support
From: David Miller @ 2011-07-06 1:20 UTC (permalink / raw)
To: therbert; +Cc: victor, netdev, willemb
In-Reply-To: <CA+mtBx_MtQGqNT6iungW7eyStpvLEGYsgXQ8=mYq_JR8jw3=DQ@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Tue, 5 Jul 2011 17:46:36 -0700
> Thanks for these patches! Is it possible you could use an alternative
> term than "fanout"? I think this may be more often associated with a
> transmit operation (e.g. multicast fanout).
I've never heard such terminology myself.
Sorry, the fanout name is staying :-)
> Also, another useful mode of steering would be to steer packets to a
> socket which was recently processed by a thread running on the same
> CPU; somewhat analogous to RFS (cc'ed WIllem Bruijn who is already
> working on this I believe).
This sounds like a good way to overload a local socket and prevent
pushing the work to lesser used sockets on other cpus.
^ permalink raw reply
* Re: usbnet suspend issue
From: David Miller @ 2011-07-06 1:11 UTC (permalink / raw)
To: C.Fries, qcf001; +Cc: netdev, stable
In-Reply-To: <CADuEq9DosCUpw9CnLrgQPXFojeCqEy-BHfZd1_BgvRJdFFQ9Ow@mail.gmail.com>
Patch submitted as binary attachment instead of plain text inline that
we can read and evaluate directly in our mail clients.
Also, if you submit this as a binary attachment, automated patch
management tools, such as patchwork, we use cannot track the patch.
Sorry, this is not the proper way to submit a patch.
Also get rid of the "Change-Id:" in your commit message, it has
no meaning.
^ permalink raw reply
* RE: [RFC] non-preemptible kernel socket for RAMster
From: Dan Magenheimer @ 2011-07-06 1:05 UTC (permalink / raw)
To: Loke, Chetan, netdev; +Cc: Konrad Wilk, linux-mm
In-Reply-To: <D3F292ADF945FB49B35E96C94C2061B91257DCA8@nsmail.netscout.com>
> From: Loke, Chetan [mailto:Chetan.Loke@netscout.com]
> Subject: RE: [RFC] non-preemptible kernel socket for RAMster
>
> > From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
>
> > Actually, RAMster is using a much more flexible type of
> > RAM-drive; it is built on top of Transcendent Memory
> > and on top of zcache (and thus on top of cleancache and
> > frontswap). A RAM-drive is fixed size so is not very suitable
> > for the flexibility required for RAMster. For example,
> > suppose you have two machines A and B. At one point in
> > time A is overcommitted and needs to swap and B is relatively
> > idle. Then later, B is overcommitted and needs to swap and
> > A is relatively idle. RAMster can handle this entirely
> > dynamically, a RAM-drive cannot.
>
> Again, iff NBD works with a ram-drive then you really wouldn't need to
> do anything. How often are you going to re-size your remote-SWAP? Plus,
> you can make nbd-server listen on multiple ports - Google(Linux NBD)
> returned: http://www.fi.muni.cz/~kripac/orac-nbd/ . Look at the
> nbd-server code to see if it launches multiple kernel-threads for
> servicing different ports. If not, one can enhance it and scale that way
> too. But nbd-server today can service multiple-ports(that is effectively
> servicing multiple clients). So why not add NBD-filesystem-filters to
> make it point to local/remote swap?
Well, we may be talking past each other, but the RAMster answer to:
> How often are you going to re-size your remote-SWAP?
is "as often as the working set changes on any machine in the
cluster", meaning *constantly*, entirely dynamically! How
about a more specific example: Suppose you have 2 machines,
each with 8GB of memory. 99% of the time each machine is
chugging along just fine and doesn't really need more than 4GB,
and may even use less than 1GB a large part of the time.
But very now and then, one of the machines randomly needs
9GB, 10GB, maybe even 12GB of memory. This would normally
result in swapping. (Most system administrators won't even
have this much information... they'll just know they are
seeing swapping and decide they need to buy more RAM.)
With NBD to a ram-drive, each machine would need to pre-allocate
4GB of RAM for the RAM-drive, leaving only 4GB of RAM for
the "local" RAM. The result will actually be MORE swapping
because a fixed amount of RAM has been pre-reserved for the
other machine's swap. With RAMster, everything is done dynamically,
so all that matters is the maximum of the sum of the RAM
used. You may even be able to *remove* ~2GB of RAM from each
of the systems and still never see any swapping to disk.
> > Thanks. Could you provide a pointer for this? I found
> > the SCST sourceforge page but no obvious references to
> > scst-in-ram-mode. (But also, since it appears to be
> > SCSI-related, I wonder if it also assumes a fixed size
> > target device, RAM or disk or ??)
>
> Yes, it is SCSI. You should be looking for SCST I/O modes. Read some
> docs and then send an email to the scst-mailing-list. If you speak about
> block-IO-performance then FC(in its class of price/performance factor)
> is more than capable of handling any workload. FC is a protocol designed
> for storage. No exotic fabric other than FC is needed.
> Folks who start with ethernet for block-IO, always start with bare
> minimal code and then for squeezing block-IO performance(aka version 2
> of the product), keep hacking repeatedly or go for a link-speed upgrade.
> Start with FC, period.
My point was that block I/O devices (AFAIK) always present a fixed
"size" to the kernel, and if this is also true of scst-in-ram-mode,
the same problem as swap-over-NBD occurs... it's not dynamic.
RAMster does not present a block-I/O storage-like interface;
it's using the Transcendent Memory interface, which is designed
for "slow RAM" of an unknown-and-dynamic size.
I'm not a storage expert either, but I do wonder if "no exotic
fabric other than FC" isn't an oxymoron ;-) FC is certainly
too exotic for me.
Dan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 0/2] AF_PACKET fanout support
From: Tom Herbert @ 2011-07-06 0:46 UTC (permalink / raw)
To: David Miller; +Cc: victor, netdev, Willem Bruijn
In-Reply-To: <20110704.212002.1680758539791986198.davem@davemloft.net>
Dave,
Thanks for these patches! Is it possible you could use an alternative
term than "fanout"? I think this may be more often associated with a
transmit operation (e.g. multicast fanout).
Also, another useful mode of steering would be to steer packets to a
socket which was recently processed by a thread running on the same
CPU; somewhat analogous to RFS (cc'ed WIllem Bruijn who is already
working on this I believe).
Tom
On Mon, Jul 4, 2011 at 9:20 PM, David Miller <davem@davemloft.net> wrote:
>
> This is a fully functional version, I've tested both hash and
> load-balance modes successfully. I plan to commit this to
> net-next-2.6 very soon.
>
> Below is a test program that other people can play with
> if they want. It basically creates 4 threads, and creates
> an AF_PACKET fanout amongst them. Each thread prints out
> it's pid in parentheses every time it receives 10 packets.
> After each thread processes 10,000 packets, it exits.
>
> Try things like "./test eth0 hash", "./test eth0 lb", etc.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> --------------------
> #include <stddef.h>
> #include <stdlib.h>
> #include <stdio.h>
> #include <string.h>
>
> #include <sys/types.h>
> #include <sys/wait.h>
> #include <sys/socket.h>
> #include <sys/ioctl.h>
>
> #include <unistd.h>
>
> #include <linux/if_ether.h>
> #include <linux/if_packet.h>
>
> #include <net/if.h>
>
> static const char *device_name;
> static int fanout_type;
> static int fanout_id;
>
> #ifndef PACKET_FANOUT
> #define PACKET_FANOUT 18
> #define PACKET_FANOUT_HASH 0
> #define PACKET_FANOUT_LB 1
> #endif
>
> static int setup_socket(void)
> {
> int err, fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_IP));
> struct sockaddr_ll ll;
> struct ifreq ifr;
> int fanout_arg;
>
> if (fd < 0) {
> perror("socket");
> return EXIT_FAILURE;
> }
>
> memset(&ifr, 0, sizeof(ifr));
> strcpy(ifr.ifr_name, device_name);
> err = ioctl(fd, SIOCGIFINDEX, &ifr);
> if (err < 0) {
> perror("SIOCGIFINDEX");
> return EXIT_FAILURE;
> }
>
> memset(&ll, 0, sizeof(ll));
> ll.sll_family = AF_PACKET;
> ll.sll_ifindex = ifr.ifr_ifindex;
> err = bind(fd, (struct sockaddr *) &ll, sizeof(ll));
> if (err < 0) {
> perror("bind");
> return EXIT_FAILURE;
> }
>
> fanout_arg = (fanout_id | (fanout_type << 16));
> err = setsockopt(fd, SOL_PACKET, PACKET_FANOUT,
> &fanout_arg, sizeof(fanout_arg));
> if (err) {
> perror("setsockopt");
> return EXIT_FAILURE;
> }
>
> return fd;
> }
>
> static void fanout_thread(void)
> {
> int fd = setup_socket();
> int limit = 10000;
>
> if (fd < 0)
> exit(fd);
>
> while (limit-- > 0) {
> char buf[1600];
> int err;
>
> err = read(fd, buf, sizeof(buf));
> if (err < 0) {
> perror("read");
> exit(EXIT_FAILURE);
> }
> if ((limit % 10) == 0)
> fprintf(stdout, "(%d) \n", getpid());
> }
>
> fprintf(stdout, "%d: Received 10000 packets\n", getpid());
>
> close(fd);
> exit(0);
> }
>
> int main(int argc, char **argp)
> {
> int fd, err;
> int i;
>
> if (argc != 3) {
> fprintf(stderr, "Usage: %s INTERFACE {hash|lb}\n", argp[0]);
> return EXIT_FAILURE;
> }
>
> if (!strcmp(argp[2], "hash"))
> fanout_type = PACKET_FANOUT_HASH;
> else if (!strcmp(argp[2], "lb"))
> fanout_type = PACKET_FANOUT_LB;
> else {
> fprintf(stderr, "Unknown fanout type [%s]\n", argp[2]);
> exit(EXIT_FAILURE);
> }
>
> device_name = argp[1];
> fanout_id = getpid() & 0xffff;
>
> for (i = 0; i < 4; i++) {
> pid_t pid = fork();
>
> switch (pid) {
> case 0:
> fanout_thread();
>
> case -1:
> perror("fork");
> exit(EXIT_FAILURE);
> }
> }
>
> for (i = 0; i < 4; i++) {
> int status;
>
> wait(&status);
> }
>
> return 0;
> }
> --
> 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
^ permalink raw reply
* Re: [PATCH] vmxnet3: fix starving rx ring whenoc_skb kb fails
From: Shreyas Bhatewara @ 2011-07-06 0:34 UTC (permalink / raw)
To: David Miller
Cc: bhutchings@solarflare.com, pv-drivers@vmware.com,
netdev@vger.kernel.org, scottjg
In-Reply-To: <20110617.120900.550060204741705506.davem@davemloft.net>
If the rx ring is completely empty, then the device may never fire an rx
interrupt. Unfortunately, the rx interrupt is what triggers populating the
rx ring with fresh buffers, so this will cause networking to lock up.
This patch replenishes the skb in recv descriptor as soon as it is
peeled off while processing rx completions. If the skb/buffer
allocation fails, existing one is recycled and the packet in hand is
dropped. This way none of the RX desc is ever left empty, thus avoiding
starvation
Signed-off-by: Scott J. Goldman <scottjg@vmware.com>
Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
---
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 2c14736..fabcded 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -573,7 +573,7 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx,
struct vmxnet3_cmd_ring *ring = &rq->rx_ring[ring_idx];
u32 val;
- while (num_allocated < num_to_alloc) {
+ while (num_allocated <= num_to_alloc) {
struct vmxnet3_rx_buf_info *rbi;
union Vmxnet3_GenericDesc *gd;
@@ -619,9 +619,15 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx,
BUG_ON(rbi->dma_addr == 0);
gd->rxd.addr = cpu_to_le64(rbi->dma_addr);
- gd->dword[2] = cpu_to_le32((ring->gen << VMXNET3_RXD_GEN_SHIFT)
+ gd->dword[2] = cpu_to_le32((!ring->gen << VMXNET3_RXD_GEN_SHIFT)
| val | rbi->len);
+ /* Fill the last buffer but dont mark it ready, or else the
+ * device will think that the queue is full */
+ if (num_allocated == num_to_alloc)
+ break;
+
+ gd->dword[2] |= cpu_to_le32(ring->gen << VMXNET3_RXD_GEN_SHIFT);
num_allocated++;
vmxnet3_cmd_ring_adv_next2fill(ring);
}
@@ -1138,6 +1144,7 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
VMXNET3_REG_RXPROD, VMXNET3_REG_RXPROD2
};
u32 num_rxd = 0;
+ bool skip_page_frags = false;
struct Vmxnet3_RxCompDesc *rcd;
struct vmxnet3_rx_ctx *ctx = &rq->rx_ctx;
#ifdef __BIG_ENDIAN_BITFIELD
@@ -1148,11 +1155,12 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
&rxComp);
while (rcd->gen == rq->comp_ring.gen) {
struct vmxnet3_rx_buf_info *rbi;
- struct sk_buff *skb;
+ struct sk_buff *skb, *new_skb = NULL;
+ struct page *new_page = NULL;
int num_to_alloc;
struct Vmxnet3_RxDesc *rxd;
u32 idx, ring_idx;
-
+ struct vmxnet3_cmd_ring *ring = NULL;
if (num_rxd >= quota) {
/* we may stop even before we see the EOP desc of
* the current pkt
@@ -1163,6 +1171,7 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
BUG_ON(rcd->rqID != rq->qid && rcd->rqID != rq->qid2);
idx = rcd->rxdIdx;
ring_idx = rcd->rqID < adapter->num_rx_queues ? 0 : 1;
+ ring = rq->rx_ring + ring_idx;
vmxnet3_getRxDesc(rxd, &rq->rx_ring[ring_idx].base[idx].rxd,
&rxCmdDesc);
rbi = rq->buf_info[ring_idx] + idx;
@@ -1191,37 +1200,80 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
goto rcd_done;
}
+ skip_page_frags = false;
ctx->skb = rbi->skb;
- rbi->skb = NULL;
+ new_skb = dev_alloc_skb(rbi->len + NET_IP_ALIGN);
+ if (new_skb == NULL) {
+ /* Skb allocation failed, do not handover this
+ * skb to stack. Reuse it. Drop the existing pkt
+ */
+ rq->stats.rx_buf_alloc_failure++;
+ ctx->skb = NULL;
+ rq->stats.drop_total++;
+ skip_page_frags = true;
+ goto rcd_done;
+ }
pci_unmap_single(adapter->pdev, rbi->dma_addr, rbi->len,
PCI_DMA_FROMDEVICE);
skb_put(ctx->skb, rcd->len);
+
+ /* Immediate refill */
+ new_skb->dev = adapter->netdev;
+ skb_reserve(new_skb, NET_IP_ALIGN);
+ rbi->skb = new_skb;
+ rbi->dma_addr = pci_map_single(adapter->pdev,
+ rbi->skb->data, rbi->len,
+ PCI_DMA_FROMDEVICE);
+ rxd->addr = cpu_to_le64(rbi->dma_addr);
+ rxd->len = rbi->len;
+
} else {
- BUG_ON(ctx->skb == NULL);
+ BUG_ON(ctx->skb == NULL && !skip_page_frags);
+
/* non SOP buffer must be type 1 in most cases */
- if (rbi->buf_type == VMXNET3_RX_BUF_PAGE) {
- BUG_ON(rxd->btype != VMXNET3_RXD_BTYPE_BODY);
+ BUG_ON(rbi->buf_type != VMXNET3_RX_BUF_PAGE);
+ BUG_ON(rxd->btype != VMXNET3_RXD_BTYPE_BODY);
- if (rcd->len) {
- pci_unmap_page(adapter->pdev,
- rbi->dma_addr, rbi->len,
- PCI_DMA_FROMDEVICE);
+ /* If an sop buffer was dropped, skip all
+ * following non-sop fragments. They will be reused.
+ */
+ if (skip_page_frags)
+ goto rcd_done;
- vmxnet3_append_frag(ctx->skb, rcd, rbi);
- rbi->page = NULL;
- }
- } else {
- /*
- * The only time a non-SOP buffer is type 0 is
- * when it's EOP and error flag is raised, which
- * has already been handled.
+ new_page = alloc_page(GFP_ATOMIC);
+ if (unlikely(new_page == NULL)) {
+ /* Replacement page frag could not be allocated.
+ * Reuse this page. Drop the pkt and free the
+ * skb which contained this page as a frag. Skip
+ * processing all the following non-sop frags.
*/
- BUG_ON(true);
+ rq->stats.rx_buf_alloc_failure++;
+ dev_kfree_skb(ctx->skb);
+ ctx->skb = NULL;
+ skip_page_frags = true;
+ goto rcd_done;
+ }
+
+ if (rcd->len) {
+ pci_unmap_page(adapter->pdev,
+ rbi->dma_addr, rbi->len,
+ PCI_DMA_FROMDEVICE);
+
+ vmxnet3_append_frag(ctx->skb, rcd, rbi);
}
+
+ /* Immediate refill */
+ rbi->page = new_page;
+ rbi->dma_addr = pci_map_page(adapter->pdev, rbi->page,
+ 0, PAGE_SIZE,
+ PCI_DMA_FROMDEVICE);
+ rxd->addr = cpu_to_le64(rbi->dma_addr);
+ rxd->len = rbi->len;
}
+
skb = ctx->skb;
if (rcd->eop) {
skb->len += skb->data_len;
@@ -1243,26 +1295,27 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
}
rcd_done:
- /* device may skip some rx descs */
- rq->rx_ring[ring_idx].next2comp = idx;
- VMXNET3_INC_RING_IDX_ONLY(rq->rx_ring[ring_idx].next2comp,
- rq->rx_ring[ring_idx].size);
-
- /* refill rx buffers frequently to avoid starving the h/w */
- num_to_alloc = vmxnet3_cmd_ring_desc_avail(rq->rx_ring +
- ring_idx);
- if (unlikely(num_to_alloc > VMXNET3_RX_ALLOC_THRESHOLD(rq,
- ring_idx, adapter))) {
- vmxnet3_rq_alloc_rx_buf(rq, ring_idx, num_to_alloc,
- adapter);
-
- /* if needed, update the register */
- if (unlikely(rq->shared->updateRxProd)) {
- VMXNET3_WRITE_BAR0_REG(adapter,
- rxprod_reg[ring_idx] + rq->qid * 8,
- rq->rx_ring[ring_idx].next2fill);
- rq->uncommitted[ring_idx] = 0;
- }
+ /* device may have skipped some rx descs */
+ ring->next2comp = idx;
+ num_to_alloc = vmxnet3_cmd_ring_desc_avail(ring);
+ ring = rq->rx_ring + ring_idx;
+ while (num_to_alloc) {
+ vmxnet3_getRxDesc(rxd, &ring->base[ring->next2fill].rxd,
+ &rxCmdDesc);
+ BUG_ON(!rxd->addr);
+
+ /* Recv desc is ready to be used by the device */
+ rxd->gen = ring->gen;
+ vmxnet3_cmd_ring_adv_next2fill(ring);
+ num_to_alloc--;
+ }
+
+ /* if needed, update the register */
+ if (unlikely(rq->shared->updateRxProd)) {
+ VMXNET3_WRITE_BAR0_REG(adapter,
+ rxprod_reg[ring_idx] + rq->qid * 8,
+ ring->next2fill);
+ rq->uncommitted[ring_idx] = 0;
}
vmxnet3_comp_ring_adv_next2proc(&rq->comp_ring);
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 2e37985..a9cb3fa 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.1.9.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.1.14.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01010900
+#define VMXNET3_DRIVER_VERSION_NUM 0x01010E00
#if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
^ permalink raw reply related
* Re: [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP setup
From: Herbert Xu @ 2011-07-05 23:58 UTC (permalink / raw)
To: Michael Guntsche; +Cc: netdev, davem
In-Reply-To: <20110705204200@it-loops.com>
Michael Guntsche <mike@it-loops.com> wrote:
>
> Looking at the changes between rc5 and rc6 I noticed commit
>
> bd4265fe365c0f3945d: bridge: Only flood unregistered groups to routers
Oops, that was definitely my fault. This patch should fix your
problem.
bridge: Always flood broadcast packets
As is_multicast_ether_addr returns true on broadcast packets as
well, we need to explicitly exclude broadcast packets so that
they're always flooded. This wasn't an issue before as broadcast
packets were considered to be an unregistered multicast group,
which were always flooded. However, as we now only flood such
packets to router ports, this is no longer acceptable.
Reported-by: Michael Guntsche <mike@it-loops.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index c188c80..32b8f9f 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -49,7 +49,9 @@ netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct net_device *dev)
skb_pull(skb, ETH_HLEN);
rcu_read_lock();
- if (is_multicast_ether_addr(dest)) {
+ if (is_broadcast_ether_addr(dest))
+ br_flood_deliver(br, skb);
+ else if (is_multicast_ether_addr(dest)) {
if (unlikely(netpoll_tx_running(dev))) {
br_flood_deliver(br, skb);
goto out;
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index f3ac1e8..f06ee39 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -60,7 +60,7 @@ int br_handle_frame_finish(struct sk_buff *skb)
br = p->br;
br_fdb_update(br, p, eth_hdr(skb)->h_source);
- if (is_multicast_ether_addr(dest) &&
+ if (!is_broadcast_ether_addr(dest) && is_multicast_ether_addr(dest) &&
br_multicast_rcv(br, p, skb))
goto drop;
@@ -77,7 +77,9 @@ int br_handle_frame_finish(struct sk_buff *skb)
dst = NULL;
- if (is_multicast_ether_addr(dest)) {
+ if (is_broadcast_ether_addr(dest))
+ skb2 = skb;
+ else if (is_multicast_ether_addr(dest)) {
mdst = br_mdb_get(br, skb);
if (mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)) {
if ((mdst && mdst->mglist) ||
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* RE: [RFC] non-preemptible kernel socket for RAMster
From: Loke, Chetan @ 2011-07-05 22:27 UTC (permalink / raw)
To: Dan Magenheimer, netdev; +Cc: Konrad Wilk, linux-mm
In-Reply-To: <704d094e-7b81-480f-8363-327218d1b0ea@default>
> -----Original Message-----
> From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
> Sent: July 05, 2011 3:19 PM
> To: Loke, Chetan; netdev@vger.kernel.org
> Cc: Konrad Wilk; linux-mm
> Subject: RE: [RFC] non-preemptible kernel socket for RAMster
>
> Actually, RAMster is using a much more flexible type of
> RAM-drive; it is built on top of Transcendent Memory
> and on top of zcache (and thus on top of cleancache and
> frontswap). A RAM-drive is fixed size so is not very suitable
> for the flexibility required for RAMster. For example,
> suppose you have two machines A and B. At one point in
> time A is overcommitted and needs to swap and B is relatively
> idle. Then later, B is overcommitted and needs to swap and
> A is relatively idle. RAMster can handle this entirely
> dynamically, a RAM-drive cannot.
Again, iff NBD works with a ram-drive then you really wouldn't need to
do anything. How often are you going to re-size your remote-SWAP? Plus,
you can make nbd-server listen on multiple ports - Google(Linux NBD)
returned: http://www.fi.muni.cz/~kripac/orac-nbd/ . Look at the
nbd-server code to see if it launches multiple kernel-threads for
servicing different ports. If not, one can enhance it and scale that way
too. But nbd-server today can service multiple-ports(that is effectively
servicing multiple clients). So why not add NBD-filesystem-filters to
make it point to local/remote swap?
>
> Thanks. Could you provide a pointer for this? I found
> the SCST sourceforge page but no obvious references to
> scst-in-ram-mode. (But also, since it appears to be
> SCSI-related, I wonder if it also assumes a fixed size
> target device, RAM or disk or ??)
>
Yes, it is SCSI. You should be looking for SCST I/O modes. Read some
docs and then send an email to the scst-mailing-list. If you speak about
block-IO-performance then FC(in its class of price/performance factor)
is more than capable of handling any workload. FC is a protocol designed
for storage. No exotic fabric other than FC is needed.
Folks who start with ethernet for block-IO, always start with bare
minimal code and then for squeezing block-IO performance(aka version 2
of the product), keep hacking repeatedly or go for a link-speed upgrade.
Start with FC, period.
> Dan
Chetan Loke
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Neil Horman @ 2011-07-05 22:06 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexey Zaytsev, Michael Büsch, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1309896940.2545.34.camel@edumazet-laptop>
On Tue, Jul 05, 2011 at 10:15:40PM +0200, Eric Dumazet wrote:
> Le mardi 05 juillet 2011 à 22:02 +0200, Eric Dumazet a écrit :
> > Le mardi 05 juillet 2011 à 15:53 -0400, Neil Horman a écrit :
> > > I think this is a goo idea, at least for testing. It seems odd to me that we
> > > have the B44_DMARX_PTR value which indicates (ostensibly) the pointer to the
> > > descriptor to be processed next (the documentation isnt' very verbose on the
> > > subject), along with the EOT bit on a descriptor. It seems like both the
> > > register and the bit are capable of conveying the same (or at least overlapping)
> > > information.
> > >
> > > I think what I'm having the most trouble with is understanding when the hw looks
> > > at the EOT bit in the descriptor. If it completes a DMA and sees the EOT bit
> > > set, does the next DMA occur to the descriptor pointed to by the DMARX_ADDR
> > > register? Of does it stall until such time as the DMARX_PTR register is rotated
> > > around? What if it doesn't see the EOT bit set? Does it just keep going with
> > > the next descriptor?
>
> Since there is no OWN bit (at least not on the online doc I got : it
> says the rx_ring is read only by the NIC), I would say we really need to
> advance DMARX_PTR to signal NIC a new entry is available for following
> incoming frames.
>
> This is the reason rx_pending max value is B44_RX_RING_SIZE - 1, or else
> chip could loop on a circular rx_ring.
>
Agree, although that still leaves open the question of what exactly should get
written into the DMARX_PTR. Is it an index of the descriptor number, or a byte
offset.
Regardless, I think we ned to fix up the looping so as to prevent an EOT reset
jumping outside of our valid ring window. Alexey, theres better ways to do
this, but if in the interim, you could please try this patch, it makes the valid
receive window for b44 cover the entire ring, so as to avoid this problem. It
will at least help support or refute this theory. Note its not exactly the same
as my previous patch. If you set the default ring pending to 512, the math in
the b44_alloc_rx_skb path is wrong, we skip the EOT bit as well as the first
entry in the ring. At 511 it should work out properly.
Thanks
Neil
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 3d247f3..b7f5ed1 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -57,7 +57,7 @@
#define B44_MAX_MTU 1500
#define B44_RX_RING_SIZE 512
-#define B44_DEF_RX_RING_PENDING 200
+#define B44_DEF_RX_RING_PENDING 511
#define B44_RX_RING_BYTES (sizeof(struct dma_desc) * \
B44_RX_RING_SIZE)
#define B44_TX_RING_SIZE 512
>
>
>
> --
> 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
>
^ permalink raw reply related
* Hello
From: Dulce Cupen @ 2011-07-05 19:10 UTC (permalink / raw)
Please be informed that you have
$250,000.00 Lodged in our Western Union to
transfer to you as Compensation.
Please Contact Email: wumt.solodavid.uk@msnzone.cn
^ permalink raw reply
* Hello
From: Dulce Cupen @ 2011-07-05 19:47 UTC (permalink / raw)
Please be informed that you have
$250,000.00 Lodged in our Western Union to
transfer to you as Compensation.
Please Contact Email: wumt.solodavid.uk@msnzone.cn
^ 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