* Re: [PATCH] tg3: Make the RSS indir tbl admin configurable
From: Ben Hutchings @ 2011-12-16 3:04 UTC (permalink / raw)
To: Matt Carlson; +Cc: davem, netdev, Michael Chan
In-Reply-To: <1323996466-8139-1-git-send-email-mcarlson@broadcom.com>
On Thu, 2011-12-15 at 16:47 -0800, Matt Carlson wrote:
> This patch adds the ethtool callbacks necessary to change the rss
> indirection table from userspace. When setting the indirection table
> through set_rxfh_indir, an indirection table size of zero is
> interpreted to mean that the admin wants to relinquish control of the
> table to the driver. Should the number of interrupts change (e.g.
> across a close / open call, or through a reset), any indirection table
> values that exceed the number of RSS queues or interrupt vectors will
> be automatically scaled back to values within range.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
No I didn't!
Ben.
> Reviewed-by: Benjamin Li <benli@broadcom.com>
> ---
> drivers/net/ethernet/broadcom/tg3.c | 126 ++++++++++++++++++++++++++++++++++-
> drivers/net/ethernet/broadcom/tg3.h | 1 +
> 2 files changed, 126 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index 8bf11ca..87f70f6 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -8229,9 +8229,19 @@ void tg3_rss_init_indir_tbl(struct tg3 *tp)
>
> if (tp->irq_cnt <= 2)
> memset(&tp->rss_ind_tbl[0], 0, sizeof(tp->rss_ind_tbl));
> - else
> + else if (tg3_flag(tp, USER_INDIR_TBL)) {
> + /* Validate table against current IRQ count */
> + for (i = 0; i < TG3_RSS_INDIR_TBL_SIZE; i++) {
> + if (tp->rss_ind_tbl[i] >= tp->irq_cnt - 1) {
> + /* Bring the index within range */
> + tp->rss_ind_tbl[i] = tp->rss_ind_tbl[i] %
> + (tp->irq_cnt - 1);
> + }
> + }
> + } else {
> for (i = 0; i < TG3_RSS_INDIR_TBL_SIZE; i++)
> tp->rss_ind_tbl[i] = i % (tp->irq_cnt - 1);
> + }
> }
>
> void tg3_rss_write_indir_tbl(struct tg3 *tp)
> @@ -10719,6 +10729,117 @@ static int tg3_get_sset_count(struct net_device *dev, int sset)
> }
> }
>
> +static int tg3_get_rxnfc(struct net_device *dev, struct ethtool_rxnfc *info,
> + u32 *rules __always_unused)
> +{
> + struct tg3 *tp = netdev_priv(dev);
> +
> + if (!tg3_flag(tp, SUPPORT_MSIX))
> + return -EOPNOTSUPP;
> +
> + switch (info->cmd) {
> + case ETHTOOL_GRXRINGS:
> + if (netif_running(tp->dev))
> + info->data = tp->irq_cnt;
> + else {
> + info->data = num_online_cpus();
> + if (info->data > TG3_IRQ_MAX_VECS_RSS)
> + info->data = TG3_IRQ_MAX_VECS_RSS;
> + }
> +
> + /* The first interrupt vector only
> + * handles link interrupts.
> + */
> + info->data -= 1;
> + return 0;
> +
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +
> +static int tg3_get_rxfh_indir(struct net_device *dev,
> + struct ethtool_rxfh_indir *indir)
> +{
> + struct tg3 *tp = netdev_priv(dev);
> + int i;
> +
> + if (!tg3_flag(tp, SUPPORT_MSIX))
> + return -EOPNOTSUPP;
> +
> + if (!indir->size) {
> + indir->size = TG3_RSS_INDIR_TBL_SIZE;
> + return 0;
> + }
> +
> + if (indir->size != TG3_RSS_INDIR_TBL_SIZE)
> + return -EINVAL;
> +
> + for (i = 0; i < TG3_RSS_INDIR_TBL_SIZE; i++)
> + indir->ring_index[i] = tp->rss_ind_tbl[i];
> +
> + return 0;
> +}
> +
> +static int tg3_set_rxfh_indir(struct net_device *dev,
> + const struct ethtool_rxfh_indir *indir)
> +{
> + struct tg3 *tp = netdev_priv(dev);
> + size_t i;
> +
> + if (!tg3_flag(tp, SUPPORT_MSIX))
> + return -EOPNOTSUPP;
> +
> + if (!indir->size) {
> + tg3_flag_clear(tp, USER_INDIR_TBL);
> + tg3_rss_init_indir_tbl(tp);
> + } else {
> + int limit;
> +
> + /* Validate size and indices */
> + if (indir->size != TG3_RSS_INDIR_TBL_SIZE)
> + return -EINVAL;
> +
> + if (netif_running(dev))
> + limit = tp->irq_cnt;
> + else {
> + limit = num_online_cpus();
> + if (limit > TG3_IRQ_MAX_VECS_RSS)
> + limit = TG3_IRQ_MAX_VECS_RSS;
> + }
> +
> + /* The first interrupt vector only
> + * handles link interrupts.
> + */
> + limit -= 1;
> +
> + /* Check the indices in the table.
> + * Leave the existing table unmodified
> + * if an error is detected.
> + */
> + for (i = 0; i < TG3_RSS_INDIR_TBL_SIZE; i++)
> + if (indir->ring_index[i] >= limit)
> + return -EINVAL;
> +
> + tg3_flag_set(tp, USER_INDIR_TBL);
> +
> + for (i = 0; i < TG3_RSS_INDIR_TBL_SIZE; i++)
> + tp->rss_ind_tbl[i] = indir->ring_index[i];
> + }
> +
> + if (!netif_running(dev) || !tg3_flag(tp, ENABLE_RSS))
> + return 0;
> +
> + /* It is legal to write the indirection
> + * table while the device is running.
> + */
> + tg3_full_lock(tp, 0);
> + tg3_rss_write_indir_tbl(tp);
> + tg3_full_unlock(tp);
> +
> + return 0;
> +}
> +
> static void tg3_get_strings(struct net_device *dev, u32 stringset, u8 *buf)
> {
> switch (stringset) {
> @@ -11949,6 +12070,9 @@ static const struct ethtool_ops tg3_ethtool_ops = {
> .get_coalesce = tg3_get_coalesce,
> .set_coalesce = tg3_set_coalesce,
> .get_sset_count = tg3_get_sset_count,
> + .get_rxnfc = tg3_get_rxnfc,
> + .get_rxfh_indir = tg3_get_rxfh_indir,
> + .set_rxfh_indir = tg3_set_rxfh_indir,
> };
>
> static void __devinit tg3_get_eeprom_size(struct tg3 *tp)
> diff --git a/drivers/net/ethernet/broadcom/tg3.h b/drivers/net/ethernet/broadcom/tg3.h
> index aea8f72..4800595 100644
> --- a/drivers/net/ethernet/broadcom/tg3.h
> +++ b/drivers/net/ethernet/broadcom/tg3.h
> @@ -2932,6 +2932,7 @@ enum TG3_FLAGS {
> TG3_FLAG_APE_HAS_NCSI,
> TG3_FLAG_4K_FIFO_LIMIT,
> TG3_FLAG_RESET_TASK_PENDING,
> + TG3_FLAG_USER_INDIR_TBL,
> TG3_FLAG_5705_PLUS,
> TG3_FLAG_IS_5788,
> TG3_FLAG_5750_PLUS,
--
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: drivers/net/usb/asix: bug in asix_get_wol
From: ASIX Allan Email [office] @ 2011-12-16 3:37 UTC (permalink / raw)
To: 'Grant Grundler', 'Eugene'
Cc: netdev, 'Freddy Xin',
ASIX Louis [蘇威陸]
In-Reply-To: <CANEJEGvz2ZHD_ZNJm_WeKCdVE9pmSQJY5dCe8hNayAS0MFN=-Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2784 bytes --]
Dear Grant and Eugene,
Please refer to the attached file and below statements to modify the asix_get_wol() routine and let us know if this suggestion can solve your issues or not? Thanks a lot.
================
static void
asix_get_wol(struct net_device *net, struct ethtool_wolinfo *wolinfo)
{
struct usbnet *dev = netdev_priv(net);
u8 opt;
if (asix_read_cmd(dev, AX_CMD_READ_MONITOR_MODE, 0, 0, 1, &opt) < 0) {
wolinfo->supported = 0;
wolinfo->wolopts = 0;
return;
}
wolinfo->supported = WAKE_PHY | WAKE_MAGIC;
wolinfo->wolopts = 0;
if (opt & AX_MONITOR_LINK)
wolinfo->wolopts |= WAKE_PHY;
if (opt & AX_MONITOR_MAGIC)
wolinfo->wolopts |= WAKE_MAGIC;
}
---
Best regards,
Allan Chou
Technical Support Division
ASIX Electronics Corporation
TEL: 886-3-5799500 ext.228
FAX: 886-3-5799558
E-mail: allan@asix.com.tw
http://www.asix.com.tw/
-----Original Message-----
From: grundler@google.com [mailto:grundler@google.com] On Behalf Of Grant Grundler
Sent: Friday, December 16, 2011 12:48 AM
To: Eugene; Allan Chou
Cc: netdev@vger.kernel.org; Freddy Xin
Subject: Re: drivers/net/usb/asix: bug in asix_get_wol
On Tue, Dec 13, 2011 at 5:03 AM, Eugene <elubarsky@gmail.com> wrote:
> Hi Grant,
>
>
> The problem is that, as it's currently written, asix_get_wol always
> returns that wake-on-lan is disabled.
I think that was the intent.
Allan, can you please confirm?
thanks,
grant
>
>
> Cheers,
> Eugene
>
> On 12 December 2011 10:29, Grant Grundler <grundler@chromium.org> wrote:
>> [+freddy/allan @ ASIX]
>>
>> On Sat, Dec 10, 2011 at 5:02 PM, Eugene <elubarsky@gmail.com> wrote:
>>> Dear kernel devs,
>>>
>>> Thanks for the commit at
>>> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=4ad1438f025ed8d1e4e95a796ca7f0ad5a22c378,
>>> It successfully stops my adapter from dying when wake-on-lan gets
>>> enabled.
>>
>> Hi Eugene!
>> thanks for the "it works!" report.
>>
>>> However, I've noticed that it has broken asix_get_wol - the
>>> lines
>>>
>>> if (opt & AX_MONITOR_LINK)
>>> wolinfo->wolopts |= WAKE_PHY;
>>> if (opt & AX_MONITOR_MAGIC)
>>> wolinfo->wolopts |= WAKE_MAGIC;
>>>
>>> have been accidentally removed.
>>
>> This wasn't by accident. This comment in the commit log perhaps
>> doesn't explain sufficiently:
>> | Remove MONITOR_MODE. In this mode, Received packets are not buffered when
>> | the remote wakeup is enabled.
>>
>>> The vendor driver has them, and I've
>>> successfully tested a kernel with these lines included. The change is
>>> too small for me to bother sending in a properly formatted patch...
>>
>> "Too small"? No such thing. :)
>>
>> cheers,
>> grant
[-- Attachment #2: asix_driver_from_Google_Submit_20111216.tar.gz --]
[-- Type: application/octet-stream, Size: 253437 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 3/3] ethtool: Define and apply a default policy for RX flow hash indirection
From: Shreyas Bhatewara @ 2011-12-16 3:38 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-net-drivers, Matt Carlson, Eilon Greenstein,
Dimitris Michailidis, netdev, VMware, Inc., David Miller
In-Reply-To: <1323993409.2773.28.camel@bwh-desktop>
----- Original Message -----
> All drivers that support modification of the RX flow hash indirection
> table initialise it in the same way: RX rings are assigned to table
> entries in rotation. Make that default policy explicit by having
> them
> call a ethtool_rxfh_indir_default() function.
>
> In the ethtool core, add support for a zero size value for
> ETHTOOL_SRXFHINDIR, which resets the table to this default.
>
> Partly-suggested-by: Matt Carlson <mcarlson@broadcom.com>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> The bnx2x, cxgb4 and vmxnet3 changes are compile-tested only.
>
Looks good. Thanks for working on this.
Acked-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
^ permalink raw reply
* Re: nonlocal_bind and IPv6
From: Maciej Żenczykowski @ 2011-12-16 3:58 UTC (permalink / raw)
To: Vincent Bernat; +Cc: netdev, davem, yoshfuji
In-Reply-To: <1323879648-419-1-git-send-email-bernat@luffy.cx>
why not simply use the IP_TRANSPARENT or IP_FREEBIND socket options?
On Wed, Dec 14, 2011 at 08:20, Vincent Bernat <bernat@luffy.cx> wrote:
> This is a second tentative to port ip_nonlocal_bind to IPv6. The two
> patches are independant. The first patch enables
> net.ipv6.ip_nonlocal_bind and is "namespace aware". The second patch
> modifies net.ipv4.ip_nonlocal_bind to also be "namespace aware". I
> don't know if this is something important.
>
> I did not test the SCTP part of the second patch (but it compiles).
>
> Documentation/networking/ip-sysctl.txt | 5 +++++
> include/net/netns/ipv4.h | 1 +
> include/net/netns/ipv6.h | 1 +
> net/ipv4/af_inet.c | 6 +-----
> net/ipv4/ping.c | 2 +-
> net/ipv4/sysctl_net_ipv4.c | 16 +++++++++-------
> net/ipv6/af_inet6.c | 6 ++++--
> net/ipv6/sysctl_net_ipv6.c | 8 ++++++++
> net/sctp/protocol.c | 2 +-
> 9 files changed, 31 insertions(+), 16 deletions(-)
>
> --
> 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 14/15] module_param: make bool parameters really bool (net & drivers/net)
From: David Miller @ 2011-12-16 4:15 UTC (permalink / raw)
To: rusty; +Cc: joe, linux-kernel, pawel.moll, netdev
In-Reply-To: <87k45xqvfs.fsf@rustcorp.com.au>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Fri, 16 Dec 2011 09:44:31 +1030
> Dave, did you want a true/false cleanup too?
Please, this kind of stuff rots forever and not using bool properly
drives me crazy.
^ permalink raw reply
* Re: twice past the taps, thence out to net?
From: Eric Dumazet @ 2011-12-16 4:27 UTC (permalink / raw)
To: Rick Jones
Cc: Stephen Hemminger, Vijay Subramanian, tcpdump-workers, netdev,
Matthew Vick, Jeff Kirsher
In-Reply-To: <4EEA730E.5010405@hp.com>
Le jeudi 15 décembre 2011 à 14:22 -0800, Rick Jones a écrit :
> On 12/15/2011 11:00 AM, Eric Dumazet wrote:
> >> Device's work better if the driver proactively manages stop_queue/wake_queue.
> >> Old devices used TX_BUSY, but newer devices tend to manage the queue
> >> themselves.
> >>
> >
> > Some 'new' drivers like igb can be fooled in case skb is gso segmented ?
> >
> > Because igb_xmit_frame_ring() needs skb_shinfo(skb)->nr_frags + 4
> > descriptors, igb should stop its queue not at MAX_SKB_FRAGS + 4, but
> > MAX_SKB_FRAGS*4
> >
> > diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
> > index 89d576c..989da36 100644
> > --- a/drivers/net/ethernet/intel/igb/igb_main.c
> > +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> > @@ -4370,7 +4370,7 @@ netdev_tx_t igb_xmit_frame_ring(struct sk_buff *skb,
> > igb_tx_map(tx_ring, first, hdr_len);
> >
> > /* Make sure there is space in the ring for the next send. */
> > - igb_maybe_stop_tx(tx_ring, MAX_SKB_FRAGS + 4);
> > + igb_maybe_stop_tx(tx_ring, MAX_SKB_FRAGS * 4);
> >
> > return NETDEV_TX_OK;
>
>
> Is there a minimum transmit queue length here? I get the impression
> that MAX_SKB_FRAGS is at least 16 and is 18 on a system with 4096 byte
> pages. The previous addition then would be OK so long as the TX queue
> was always at least 22 entries in size, but now it would have to always
> be at least 72?
>
> I guess things are "OK" at the moment:
>
> raj@tardy:~/net-next/drivers/net/ethernet/intel/igb$ grep IGB_MIN_TXD *.[ch]
> igb_ethtool.c: new_tx_count = max_t(u16, new_tx_count, IGB_MIN_TXD);
> igb.h:#define IGB_MIN_TXD 80
>
> but is that getting a little close?
>
> rick jones
Sure !
I only pointed out a possible problem, and not gave a full patch, since
we also need to change the opposite threshold (when we XON the queue at
TX completion)
You can see its not even consistent with the minimum for a single TSO
frame ! Most probably your high requeue numbers come from this too low
value given the real requirements of the hardware (4 + nr_frags
descriptors per skb)
/* How many Tx Descriptors do we need to call netif_wake_queue ? */
#define IGB_TX_QUEUE_WAKE 16
Maybe we should CC Intel guys
Could you try following patch ?
Thanks !
diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
index c69feeb..93ce118 100644
--- a/drivers/net/ethernet/intel/igb/igb.h
+++ b/drivers/net/ethernet/intel/igb/igb.h
@@ -51,8 +51,8 @@ struct igb_adapter;
/* TX/RX descriptor defines */
#define IGB_DEFAULT_TXD 256
#define IGB_DEFAULT_TX_WORK 128
-#define IGB_MIN_TXD 80
-#define IGB_MAX_TXD 4096
+#define IGB_MIN_TXD max_t(unsigned, 80U, IGB_TX_QUEUE_WAKE * 2)
+#define IGB_MAX_TXD 4096
#define IGB_DEFAULT_RXD 256
#define IGB_MIN_RXD 80
@@ -121,8 +121,11 @@ struct vf_data_storage {
#define IGB_RXBUFFER_16384 16384
#define IGB_RX_HDR_LEN IGB_RXBUFFER_512
-/* How many Tx Descriptors do we need to call netif_wake_queue ? */
-#define IGB_TX_QUEUE_WAKE 16
+/* How many Tx Descriptors should be available
+ * before calling netif_wake_subqueue() ?
+ */
+#define IGB_TX_QUEUE_WAKE (MAX_SKB_FRAGS * 4)
+
/* How many Rx Buffers do we bundle into one write to the hardware ? */
#define IGB_RX_BUFFER_WRITE 16 /* Must be power of 2 */
^ permalink raw reply related
* tc filter show not displaying anything
From: John A. Sullivan III @ 2011-12-16 4:48 UTC (permalink / raw)
To: netdev
Hello, all. I'm starting to feel really stupid and showing my newbidity
to tc. I do a:
tc filter show dev eth1
and nothing is displayed but I suspect the filter is there because if I
try to add it again, the kernel complains with:
RTNETLINK answers: File exists
We have an error talking to the kernel
Here is what I have put together so far (disregard the silly ports - it
is just for netcat testing):
tc qdisc add dev eth1 root handle 1: hfsc default 20
tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt rate 800kbit ls rate 200kbit
tc qdisc add dev eth1 parent 1:20 handle 1201 sfq perturb 10
tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt umax 16000kbit dmax 13ms rate 400kbit ls rate 1000kbit
tc qdisc add dev eth1 parent 1:10 handle 1101 sfq perturb 10
iptables -t mangle -A POSTROUTING -p 6 --syn --dport 443 -j CONNMARK --set-mark 0x10
iptables -t mangle -A POSTROUTING -p 6 -j CONNMARK --restore-mark
I then did:
root@testswitch01:~# tc filter add dev eth1 parent 1:1 protocol ip prio 1 handle 0x10 fw flowid 1:10
root@testswitch01:~# tc filter show dev eth1
root@testswitch01:~# tc filter show parent 1:1
What simple, practical thing did I mangle? Thanks - John
^ permalink raw reply
* Re: tc filter show not displaying anything
From: John Fastabend @ 2011-12-16 5:00 UTC (permalink / raw)
To: John A. Sullivan III; +Cc: netdev@vger.kernel.org
In-Reply-To: <1324010915.8451.319.camel@denise.theartistscloset.com>
On 12/15/2011 8:48 PM, John A. Sullivan III wrote:
> Hello, all. I'm starting to feel really stupid and showing my newbidity
> to tc. I do a:
> tc filter show dev eth1
> and nothing is displayed but I suspect the filter is there because if I
> try to add it again, the kernel complains with:
> RTNETLINK answers: File exists
> We have an error talking to the kernel
>
> Here is what I have put together so far (disregard the silly ports - it
> is just for netcat testing):
>
> tc qdisc add dev eth1 root handle 1: hfsc default 20
> tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
> tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt rate 800kbit ls rate 200kbit
> tc qdisc add dev eth1 parent 1:20 handle 1201 sfq perturb 10
> tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt umax 16000kbit dmax 13ms rate 400kbit ls rate 1000kbit
> tc qdisc add dev eth1 parent 1:10 handle 1101 sfq perturb 10
> iptables -t mangle -A POSTROUTING -p 6 --syn --dport 443 -j CONNMARK --set-mark 0x10
> iptables -t mangle -A POSTROUTING -p 6 -j CONNMARK --restore-mark
>
> I then did:
>
> root@testswitch01:~# tc filter add dev eth1 parent 1:1 protocol ip prio 1 handle 0x10 fw flowid 1:10
> root@testswitch01:~# tc filter show dev eth1
> root@testswitch01:~# tc filter show parent 1:1
>
> What simple, practical thing did I mangle? Thanks - John
>
#tc filter show dev eth1 parent 1:1
works here.
^ permalink raw reply
* RE: drivers/net/usb/asix: bug in asix_get_wol
From: ASIX Allan Email [office] @ 2011-12-16 5:15 UTC (permalink / raw)
To: 'Grant Grundler', 'Eugene'
Cc: netdev, 'Freddy Xin',
ASIX Louis [蘇威陸]
In-Reply-To: <CANEJEGvz2ZHD_ZNJm_WeKCdVE9pmSQJY5dCe8hNayAS0MFN=-Q@mail.gmail.com>
Resend without attachment due to below email server error.
========
----- The following addresses had permanent fatal errors -----
<grundler@chromium.org>
(reason: 552-5.7.0 Our system detected an illegal attachment on your message. Please)
<elubarsky@gmail.com>
(reason: 552-5.7.0 Our system detected an illegal attachment on your message. Please)
---
Best regards,
Allan Chou
Technical Support Division
ASIX Electronics Corporation
TEL: 886-3-5799500 ext.228
FAX: 886-3-5799558
E-mail: allan@asix.com.tw
http://www.asix.com.tw/
-----Original Message-----
From: ASIX Allan Email [office] [mailto:allan@asix.com.tw]
Sent: Friday, December 16, 2011 11:38 AM
To: 'Grant Grundler'; 'Eugene'
Cc: 'netdev@vger.kernel.org'; 'Freddy Xin'; ASIX Louis [蘇威陸]
Subject: RE: drivers/net/usb/asix: bug in asix_get_wol
Importance: High
Dear Grant and Eugene,
Please refer to the attached file and below statements to modify the asix_get_wol() routine and let us know if this suggestion can solve your issues or not? Thanks a lot.
================
static void
asix_get_wol(struct net_device *net, struct ethtool_wolinfo *wolinfo)
{
struct usbnet *dev = netdev_priv(net);
u8 opt;
if (asix_read_cmd(dev, AX_CMD_READ_MONITOR_MODE, 0, 0, 1, &opt) < 0) {
wolinfo->supported = 0;
wolinfo->wolopts = 0;
return;
}
wolinfo->supported = WAKE_PHY | WAKE_MAGIC;
wolinfo->wolopts = 0;
if (opt & AX_MONITOR_LINK)
wolinfo->wolopts |= WAKE_PHY;
if (opt & AX_MONITOR_MAGIC)
wolinfo->wolopts |= WAKE_MAGIC;
}
---
Best regards,
Allan Chou
Technical Support Division
ASIX Electronics Corporation
TEL: 886-3-5799500 ext.228
FAX: 886-3-5799558
E-mail: allan@asix.com.tw
http://www.asix.com.tw/
-----Original Message-----
From: grundler@google.com [mailto:grundler@google.com] On Behalf Of Grant Grundler
Sent: Friday, December 16, 2011 12:48 AM
To: Eugene; Allan Chou
Cc: netdev@vger.kernel.org; Freddy Xin
Subject: Re: drivers/net/usb/asix: bug in asix_get_wol
On Tue, Dec 13, 2011 at 5:03 AM, Eugene <elubarsky@gmail.com> wrote:
> Hi Grant,
>
>
> The problem is that, as it's currently written, asix_get_wol always
> returns that wake-on-lan is disabled.
I think that was the intent.
Allan, can you please confirm?
thanks,
grant
>
>
> Cheers,
> Eugene
>
> On 12 December 2011 10:29, Grant Grundler <grundler@chromium.org> wrote:
>> [+freddy/allan @ ASIX]
>>
>> On Sat, Dec 10, 2011 at 5:02 PM, Eugene <elubarsky@gmail.com> wrote:
>>> Dear kernel devs,
>>>
>>> Thanks for the commit at
>>> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=4ad1438f025ed8d1e4e95a796ca7f0ad5a22c378,
>>> It successfully stops my adapter from dying when wake-on-lan gets
>>> enabled.
>>
>> Hi Eugene!
>> thanks for the "it works!" report.
>>
>>> However, I've noticed that it has broken asix_get_wol - the
>>> lines
>>>
>>> if (opt & AX_MONITOR_LINK)
>>> wolinfo->wolopts |= WAKE_PHY;
>>> if (opt & AX_MONITOR_MAGIC)
>>> wolinfo->wolopts |= WAKE_MAGIC;
>>>
>>> have been accidentally removed.
>>
>> This wasn't by accident. This comment in the commit log perhaps
>> doesn't explain sufficiently:
>> | Remove MONITOR_MODE. In this mode, Received packets are not buffered when
>> | the remote wakeup is enabled.
>>
>>> The vendor driver has them, and I've
>>> successfully tested a kernel with these lines included. The change is
>>> too small for me to bother sending in a properly formatted patch...
>>
>> "Too small"? No such thing. :)
>>
>> cheers,
>> grant
^ permalink raw reply
* RE: [linux-firmware v6 2/4] rtl_nic: add new firmware for RTL8111F
From: Ben Hutchings @ 2011-12-16 5:18 UTC (permalink / raw)
To: hayeswang; +Cc: dwmw2, romieu, netdev
In-Reply-To: <81662BFCE8FC4C70A9260DE3A1A52B78@realtek.com.tw>
[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]
On Thu, 2011-11-17 at 20:16 +0800, hayeswang wrote:
>
> > -----Original Message-----
> > From: Hayeswang [mailto:hayeswang@realtek.com]
> > Sent: Wednesday, October 26, 2011 9:07 PM
> > To: dwmw2@infradead.org; ben@decadent.org.uk
> > Cc: romieu@fr.zoreil.com; netdev@vger.kernel.org; Hayeswang
> > Subject: [linux-firmware v6 2/4] rtl_nic: add new firmware
> > for RTL8111F
> >
> > Add new firmware:
> > 1. rtl_nic/rtl8168f-1.fw
> > version: 0.0.3
> > 2. rtl_nic/rtl8168f-2.fw
> > version: 0.0.3
> >
> > Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> > ---
> > WHENCE | 6 ++++++
> > rtl_nic/rtl8168f-1.fw | Bin 0 -> 3136 bytes
> > rtl_nic/rtl8168f-2.fw | Bin 0 -> 992 bytes
> > 3 files changed, 6 insertions(+), 0 deletions(-)
> > create mode 100644 rtl_nic/rtl8168f-1.fw
> > create mode 100644 rtl_nic/rtl8168f-2.fw
> >
>
> Hi sirs,
>
> Excuse me. Someone asks me these firmwares. Are these pending? Any response?
Sorry Hayes, these were held up due to the rebuiling of kernel.org
services.
I already applied your earlier changes (v0.0.2 of the 8186E and 8186F
firmware) locally. I have rebased this series of 4 patches on top of
that, and pushed the result out. Please check that I got it right.
Ben.
--
Ben Hutchings
Computers are not intelligent. They only think they are.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: tc filter show not displaying anything
From: Eric Dumazet @ 2011-12-16 5:17 UTC (permalink / raw)
To: John A. Sullivan III; +Cc: netdev
In-Reply-To: <1324010915.8451.319.camel@denise.theartistscloset.com>
Le jeudi 15 décembre 2011 à 23:48 -0500, John A. Sullivan III a écrit :
> Hello, all. I'm starting to feel really stupid and showing my newbidity
> to tc. I do a:
> tc filter show dev eth1
> and nothing is displayed but I suspect the filter is there because if I
> try to add it again, the kernel complains with:
> RTNETLINK answers: File exists
> We have an error talking to the kernel
>
> Here is what I have put together so far (disregard the silly ports - it
> is just for netcat testing):
>
> tc qdisc add dev eth1 root handle 1: hfsc default 20
> tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
> tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt rate 800kbit ls rate 200kbit
> tc qdisc add dev eth1 parent 1:20 handle 1201 sfq perturb 10
> tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt umax 16000kbit dmax 13ms rate 400kbit ls rate 1000kbit
> tc qdisc add dev eth1 parent 1:10 handle 1101 sfq perturb 10
> iptables -t mangle -A POSTROUTING -p 6 --syn --dport 443 -j CONNMARK --set-mark 0x10
> iptables -t mangle -A POSTROUTING -p 6 -j CONNMARK --restore-mark
>
> I then did:
>
> root@testswitch01:~# tc filter add dev eth1 parent 1:1 protocol ip prio 1 handle 0x10 fw flowid 1:10
> root@testswitch01:~# tc filter show dev eth1
> root@testswitch01:~# tc filter show parent 1:1
>
> What simple, practical thing did I mangle? Thanks - John
Minor point (since John already replied) : "sfq perturb 10" means you
risk out or order packets perturbation every 10 seconds. This can really
hurt TCP sessions.
Maybe we should "fix" this problem for good in SFQ.
^ permalink raw reply
* [PATCH 0/2] vhot-net: Use kvm_memslots instead of vhost_memory to translate GPA to HVA
From: zanghongyong @ 2011-12-16 5:32 UTC (permalink / raw)
To: linux-kernel
Cc: mst, levinsasha928, kvm, virtualization, netdev, xiaowei.yang,
hanweidong, wusongwei, Hongyong Zang
From: Hongyong Zang <zanghongyong@huawei.com>
Vhost-net uses its own vhost_memory, which results from user space (qemu) info,
to translate GPA to HVA. Since kernel's kvm structure already maintains the
address relationship in its member *kvm_memslots*, these patches use kernel's
kvm_memslots directly without the need of initialization and maintenance of
vhost_memory.
Hongyong Zang (2):
kvm: Introduce get_kvm_from_task
vhost-net: Use kvm_memslots for address translation
drivers/vhost/vhost.c | 53 +++++++++++++++++----------------------------
include/linux/kvm_host.h | 2 +-
virt/kvm/kvm_main.c | 13 +++++++++++
3 files changed, 34 insertions(+), 34 deletions(-)
^ permalink raw reply
* [PATCH 1/2] kvm: Introduce get_kvm_from_task
From: zanghongyong @ 2011-12-16 5:32 UTC (permalink / raw)
To: linux-kernel
Cc: mst, levinsasha928, kvm, virtualization, netdev, xiaowei.yang,
hanweidong, wusongwei, Hongyong Zang
In-Reply-To: <1324013528-3663-1-git-send-email-zanghongyong@huawei.com>
From: Hongyong Zang <zanghongyong@huawei.com>
This function finds the kvm structure from its corresponding user
space process, such as qemu process.
Signed-off-by: Hongyong Zang <zanghongyong@huawei.com>
---
include/linux/kvm_host.h | 2 +-
virt/kvm/kvm_main.c | 13 +++++++++++++
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 8c5c303..1b2f027 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -801,4 +801,4 @@ static inline bool kvm_check_request(int req, struct kvm_vcpu *vcpu)
}
#endif
-
+struct kvm *get_kvm_from_task(struct task_struct *task);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e289486..458fe29 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2664,6 +2664,19 @@ static const struct file_operations *stat_fops[] = {
[KVM_STAT_VM] = &vm_stat_fops,
};
+struct kvm* get_kvm_from_task(struct task_struct *task)
+{
+ struct kvm *kvm;
+
+ list_for_each_entry(kvm, &vm_list, vm_list) {
+ if(kvm->mm == task->mm)
+ return kvm;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(get_kvm_from_task);
+
static void kvm_init_debug(void)
{
struct kvm_stats_debugfs_item *p;
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] vhost-net: Use kvm_memslots for address translation
From: zanghongyong @ 2011-12-16 5:32 UTC (permalink / raw)
To: linux-kernel
Cc: mst, levinsasha928, kvm, virtualization, netdev, xiaowei.yang,
hanweidong, wusongwei, Hongyong Zang
In-Reply-To: <1324013528-3663-1-git-send-email-zanghongyong@huawei.com>
From: Hongyong Zang <zanghongyong@huawei.com>
Use kvm's memslots instead of vhost_memory to traslate address
from GPA to HVA.
Signed-off-by: Hongyong Zang <zanghongyong@huawei.com>
---
drivers/vhost/vhost.c | 53 ++++++++++++++++++------------------------------
1 files changed, 20 insertions(+), 33 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c14c42b..63e4322 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -11,6 +11,7 @@
* Generic code for virtio server in host kernel.
*/
+#include <linux/kvm_host.h>
#include <linux/eventfd.h>
#include <linux/vhost.h>
#include <linux/virtio_net.h>
@@ -904,23 +905,6 @@ done:
return r;
}
-static const struct vhost_memory_region *find_region(struct vhost_memory *mem,
- __u64 addr, __u32 len)
-{
- struct vhost_memory_region *reg;
- int i;
-
- /* linear search is not brilliant, but we really have on the order of 6
- * regions in practice */
- for (i = 0; i < mem->nregions; ++i) {
- reg = mem->regions + i;
- if (reg->guest_phys_addr <= addr &&
- reg->guest_phys_addr + reg->memory_size - 1 >= addr)
- return reg;
- }
- return NULL;
-}
-
/* TODO: This is really inefficient. We need something like get_user()
* (instruction directly accesses the data, with an exception table entry
* returning -EFAULT). See Documentation/x86/exception-tables.txt.
@@ -1046,40 +1030,36 @@ int vhost_init_used(struct vhost_virtqueue *vq)
return get_user(vq->last_used_idx, &vq->used->idx);
}
-static int translate_desc(struct vhost_dev *dev, u64 addr, u32 len,
+static int translate_desc(struct kvm *kvm, u64 addr, u32 len,
struct iovec iov[], int iov_size)
{
- const struct vhost_memory_region *reg;
- struct vhost_memory *mem;
+ const struct kvm_memory_slot *slot;
+ gfn_t gfn = addr >> PAGE_SHIFT;
struct iovec *_iov;
u64 s = 0;
int ret = 0;
- rcu_read_lock();
-
- mem = rcu_dereference(dev->memory);
while ((u64)len > s) {
u64 size;
if (unlikely(ret >= iov_size)) {
ret = -ENOBUFS;
break;
}
- reg = find_region(mem, addr, len);
- if (unlikely(!reg)) {
+ slot = gfn_to_memslot(kvm, gfn);
+ if (unlikely(!slot)) {
ret = -EFAULT;
break;
}
_iov = iov + ret;
- size = reg->memory_size - addr + reg->guest_phys_addr;
+ size = slot->npages*VHOST_PAGE_SIZE - addr + (slot->base_gfn<<PAGE_SHIFT);
_iov->iov_len = min((u64)len, size);
_iov->iov_base = (void __user *)(unsigned long)
- (reg->userspace_addr + addr - reg->guest_phys_addr);
+ (slot->userspace_addr + addr - (slot->base_gfn<<PAGE_SHIFT));
s += size;
addr += size;
++ret;
}
- rcu_read_unlock();
return ret;
}
@@ -1104,7 +1084,7 @@ static unsigned next_desc(struct vring_desc *desc)
return next;
}
-static int get_indirect(struct vhost_dev *dev, struct vhost_virtqueue *vq,
+static int get_indirect(struct kvm *kvm, struct vhost_virtqueue *vq,
struct iovec iov[], unsigned int iov_size,
unsigned int *out_num, unsigned int *in_num,
struct vhost_log *log, unsigned int *log_num,
@@ -1123,7 +1103,7 @@ static int get_indirect(struct vhost_dev *dev, struct vhost_virtqueue *vq,
return -EINVAL;
}
- ret = translate_desc(dev, indirect->addr, indirect->len, vq->indirect,
+ ret = translate_desc(kvm, indirect->addr, indirect->len, vq->indirect,
UIO_MAXIOV);
if (unlikely(ret < 0)) {
vq_err(vq, "Translation failure %d in indirect.\n", ret);
@@ -1163,7 +1143,7 @@ static int get_indirect(struct vhost_dev *dev, struct vhost_virtqueue *vq,
return -EINVAL;
}
- ret = translate_desc(dev, desc.addr, desc.len, iov + iov_count,
+ ret = translate_desc(kvm, desc.addr, desc.len, iov + iov_count,
iov_size - iov_count);
if (unlikely(ret < 0)) {
vq_err(vq, "Translation failure %d indirect idx %d\n",
@@ -1209,6 +1189,13 @@ int vhost_get_vq_desc(struct vhost_dev *dev, struct vhost_virtqueue *vq,
unsigned int i, head, found = 0;
u16 last_avail_idx;
int ret;
+ struct kvm *kvm = get_kvm_from_task(current);
+
+ if(unlikely(kvm == NULL)){
+ vq_err(vq, "Failed to get corresponding kvm struct of vhost-%d\n",
+ current->pid);
+ return -EFAULT;
+ }
/* Check it isn't doing very strange things with descriptor numbers. */
last_avail_idx = vq->last_avail_idx;
@@ -1274,7 +1261,7 @@ int vhost_get_vq_desc(struct vhost_dev *dev, struct vhost_virtqueue *vq,
return -EFAULT;
}
if (desc.flags & VRING_DESC_F_INDIRECT) {
- ret = get_indirect(dev, vq, iov, iov_size,
+ ret = get_indirect(kvm, vq, iov, iov_size,
out_num, in_num,
log, log_num, &desc);
if (unlikely(ret < 0)) {
@@ -1285,7 +1272,7 @@ int vhost_get_vq_desc(struct vhost_dev *dev, struct vhost_virtqueue *vq,
continue;
}
- ret = translate_desc(dev, desc.addr, desc.len, iov + iov_count,
+ ret = translate_desc(kvm, desc.addr, desc.len, iov + iov_count,
iov_size - iov_count);
if (unlikely(ret < 0)) {
vq_err(vq, "Translation failure %d descriptor idx %d\n",
--
1.7.1
^ permalink raw reply related
* Re: tc filter show not displaying anything
From: John A. Sullivan III @ 2011-12-16 5:33 UTC (permalink / raw)
To: John Fastabend; +Cc: netdev@vger.kernel.org
In-Reply-To: <4EEAD059.5010907@intel.com>
On Thu, 2011-12-15 at 21:00 -0800, John Fastabend wrote:
> On 12/15/2011 8:48 PM, John A. Sullivan III wrote:
> > Hello, all. I'm starting to feel really stupid and showing my newbidity
> > to tc. I do a:
> > tc filter show dev eth1
> > and nothing is displayed but I suspect the filter is there because if I
> > try to add it again, the kernel complains with:
> > RTNETLINK answers: File exists
> > We have an error talking to the kernel
> >
> > Here is what I have put together so far (disregard the silly ports - it
> > is just for netcat testing):
> >
> > tc qdisc add dev eth1 root handle 1: hfsc default 20
> > tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
> > tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt rate 800kbit ls rate 200kbit
> > tc qdisc add dev eth1 parent 1:20 handle 1201 sfq perturb 10
> > tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt umax 16000kbit dmax 13ms rate 400kbit ls rate 1000kbit
> > tc qdisc add dev eth1 parent 1:10 handle 1101 sfq perturb 10
> > iptables -t mangle -A POSTROUTING -p 6 --syn --dport 443 -j CONNMARK --set-mark 0x10
> > iptables -t mangle -A POSTROUTING -p 6 -j CONNMARK --restore-mark
> >
> > I then did:
> >
> > root@testswitch01:~# tc filter add dev eth1 parent 1:1 protocol ip prio 1 handle 0x10 fw flowid 1:10
> > root@testswitch01:~# tc filter show dev eth1
> > root@testswitch01:~# tc filter show parent 1:1
> >
> > What simple, practical thing did I mangle? Thanks - John
> >
>
> #tc filter show dev eth1 parent 1:1
>
> works here.
Argh!! Thanks - worked just fine - John
^ permalink raw reply
* Re: tc filter show not displaying anything
From: John A. Sullivan III @ 2011-12-16 5:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1324012627.2562.26.camel@edumazet-laptop>
On Fri, 2011-12-16 at 06:17 +0100, Eric Dumazet wrote:
> Le jeudi 15 décembre 2011 à 23:48 -0500, John A. Sullivan III a écrit :
> > Hello, all. I'm starting to feel really stupid and showing my newbidity
> > to tc. I do a:
> > tc filter show dev eth1
> > and nothing is displayed but I suspect the filter is there because if I
> > try to add it again, the kernel complains with:
> > RTNETLINK answers: File exists
> > We have an error talking to the kernel
> >
> > Here is what I have put together so far (disregard the silly ports - it
> > is just for netcat testing):
> >
> > tc qdisc add dev eth1 root handle 1: hfsc default 20
> > tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
> > tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt rate 800kbit ls rate 200kbit
> > tc qdisc add dev eth1 parent 1:20 handle 1201 sfq perturb 10
> > tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt umax 16000kbit dmax 13ms rate 400kbit ls rate 1000kbit
> > tc qdisc add dev eth1 parent 1:10 handle 1101 sfq perturb 10
> > iptables -t mangle -A POSTROUTING -p 6 --syn --dport 443 -j CONNMARK --set-mark 0x10
> > iptables -t mangle -A POSTROUTING -p 6 -j CONNMARK --restore-mark
> >
> > I then did:
> >
> > root@testswitch01:~# tc filter add dev eth1 parent 1:1 protocol ip prio 1 handle 0x10 fw flowid 1:10
> > root@testswitch01:~# tc filter show dev eth1
> > root@testswitch01:~# tc filter show parent 1:1
> >
> > What simple, practical thing did I mangle? Thanks - John
>
> Minor point (since John already replied) : "sfq perturb 10" means you
> risk out or order packets perturbation every 10 seconds. This can really
> hurt TCP sessions.
>
> Maybe we should "fix" this problem for good in SFQ.
>
>
>
Ouch! That was right out of the book so to speak. Thanks for pointing
it out - now I see it is right in the man page. Is best practice to not
perturb and live with the potentially unbalanced queues or just to set
it even higher? Thanks - John
^ permalink raw reply
* [PATCH net-next 1/2] sch_sfq: store flow_keys in skb->cb[]
From: Eric Dumazet @ 2011-12-16 5:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Instead of using automatic flow_keys variable in sfq_hash(), use storage
from skb->cb[] so that we can reuse it later if we want to rehash queues
when perturbation timer fires.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/sched/sch_sfq.c | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 46d0d77..72bccd0 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -136,16 +136,31 @@ static inline struct sfq_head *sfq_dep_head(struct sfq_sched_data *q, sfq_index
return &q->dep[val - SFQ_SLOTS];
}
+/*
+ * In order to be able to quickly rehash our queue when timer changes
+ * q->perturbation, we store flow_keys in skb->cb[]
+ */
+struct sfq_skb_cb {
+ struct flow_keys keys;
+};
+
+static inline struct sfq_skb_cb *sfq_skb_cb(const struct sk_buff *skb)
+{
+ BUILD_BUG_ON(sizeof(skb->cb) <
+ sizeof(struct qdisc_skb_cb) + sizeof(struct sfq_skb_cb));
+ return (struct sfq_skb_cb *)qdisc_skb_cb(skb)->data;
+}
+
static unsigned int sfq_hash(const struct sfq_sched_data *q,
- const struct sk_buff *skb)
+ struct sk_buff *skb)
{
- struct flow_keys keys;
+ struct flow_keys *keys = &sfq_skb_cb(skb)->keys;
unsigned int hash;
- skb_flow_dissect(skb, &keys);
- hash = jhash_3words((__force u32)keys.dst,
- (__force u32)keys.src ^ keys.ip_proto,
- (__force u32)keys.ports, q->perturbation);
+ skb_flow_dissect(skb, keys);
+ hash = jhash_3words((__force u32)keys->dst,
+ (__force u32)keys->src ^ keys->ip_proto,
+ (__force u32)keys->ports, q->perturbation);
return hash & (q->divisor - 1);
}
^ permalink raw reply related
* Re: tc filter show not displaying anything
From: Eric Dumazet @ 2011-12-16 5:42 UTC (permalink / raw)
To: John A. Sullivan III; +Cc: netdev
In-Reply-To: <1324013969.8451.326.camel@denise.theartistscloset.com>
Le vendredi 16 décembre 2011 à 00:39 -0500, John A. Sullivan III a
écrit :
> Ouch! That was right out of the book so to speak. Thanks for pointing
> it out - now I see it is right in the man page. Is best practice to not
> perturb and live with the potentially unbalanced queues or just to set
> it even higher? Thanks - John
>
I'll fix this today, because rehashing up to 128 packets is not that
expensive.
In the meantime, just use a higher timer (say 60 seconds), and if your
kernel is recent enough, use a higher 'divisor' value (default 1024, can
be up to 65536) to lower risk of hash collisions.
^ permalink raw reply
* Re: [PATCH] fix sleeping while atomic problem in sock mem_cgroup.
From: David Miller @ 2011-12-16 6:09 UTC (permalink / raw)
To: glommer-bzQdu9zFT3WakBO8gow8eQ
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A,
netdev-u79uwXL29TY76Z2rM5mHXA,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
cgroups-u79uwXL29TY76Z2rM5mHXA, sfr-3FnU+UHB4dNDw9hX6IcOSA
In-Reply-To: <1324003070-6573-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
From: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Date: Fri, 16 Dec 2011 06:37:50 +0400
> Since we can't scan the proto_list to initialize sock cgroups, as it
> holds a rwlock, and we also want to keep the code generic enough to
> avoid calling the initialization functions of protocols directly,
> I propose we keep the interested parties in a separate list. This list
> is protected by a mutex so we can sleep and do the necessary allocations.
>
> Also fixes a reference problem found by Randy Dunlap's randconfig.
>
> Signed-off-by: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Two small changes please:
1) Add an appropriate prefix to your subject line indicating the subsystem
being changed by this patch, "net: fix sleeping ..." would be appropriate
in this case.
2) Put the ifdef'ery into the memcontrol.h header file, rather than sock.c,
f.e. rename register_sock_cgroup to __register_sock_cgroup(), and
unregister_sock_cgroup to __unregister_sock_cgroup. Then create two
helper inlines in memcontrolh:
#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
static inline void register_sock_cgroup(struct proto *prot)
{
if (prot->proto_cgroup != NULL)
register_sock_cgroup(prot);
}
static inline void unregister_sock_cgroup(struct proto *prot)
{
if (prot->proto_cgroup != NULL)
unregister_sock_cgroup(prot);
}
#else
static inline void register_sock_cgroup(struct proto *prot)
{
}
static inline void unregister_sock_cgroup(struct proto *prot)
{
}
#endif
Then call these helpers unconditionally in net/core/sock.c
That way you don't need any ifdefs in that file at all.
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] tg3: Make the RSS indir tbl admin configurable
From: David Miller @ 2011-12-16 6:12 UTC (permalink / raw)
To: bhutchings; +Cc: mcarlson, netdev, mchan
In-Reply-To: <1324004674.2825.226.camel@deadeye>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 16 Dec 2011 03:04:34 +0000
> On Thu, 2011-12-15 at 16:47 -0800, Matt Carlson wrote:
>> This patch adds the ethtool callbacks necessary to change the rss
>> indirection table from userspace. When setting the indirection table
>> through set_rxfh_indir, an indirection table size of zero is
>> interpreted to mean that the admin wants to relinquish control of the
>> table to the driver. Should the number of interrupts change (e.g.
>> across a close / open call, or through a reset), any indirection table
>> values that exceed the number of RSS queues or interrupt vectors will
>> be automatically scaled back to values within range.
>>
>> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
>> Signed-off-by: Michael Chan <mchan@broadcom.com>
>> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
>
> No I didn't!
Matt, really, don't do crap like this. It's extremely rude and
completely unprofessional.
^ permalink raw reply
* Re: [PATCH v9 1/9] Basic kernel memory functionality for the Memory Controller
From: Greg Thelen @ 2011-12-16 6:20 UTC (permalink / raw)
To: Glauber Costa
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
paul-inf54ven1CmVyaH7bEyXVA, lizf-BthXqXjhjHXQFUHtdCDX3A,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, kirill-oKw7cIdHH8eLwutG50LtGA,
avagin-bzQdu9zFT3WakBO8gow8eQ, devel-GEFAQzZX7r8dnm+yROfE0A,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
cgroups-u79uwXL29TY76Z2rM5mHXA, Johannes Weiner, Michal Hocko
In-Reply-To: <1323676029-5890-2-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
On Sun, Dec 11, 2011 at 11:47 PM, Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
> +Memory limits as specified by the standard Memory Controller may or may not
> +take kernel memory into consideration. This is achieved through the file
> +memory.independent_kmem_limit. A Value different than 0 will allow for kernel
s/Value/value/
It is probably worth documenting the default value for
memory.independent_kmem_limit? I figure it would be zero at root and
and inherited from parents. But I think the implementation differs.
> @@ -277,6 +281,11 @@ struct mem_cgroup {
> */
> unsigned long move_charge_at_immigrate;
> /*
> + * Should kernel memory limits be stabilished independently
> + * from user memory ?
> + */
> + int kmem_independent_accounting;
I have no serious objection, but a full int seems like overkill for a
boolean value.
> +static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
> +{
> + int ret = 0;
> +
> + ret = cgroup_add_files(cont, ss, kmem_cgroup_files,
> + ARRAY_SIZE(kmem_cgroup_files));
> + return ret;
If you want to this function could be condensed down to:
return cgroup_add_files(...);
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: nonlocal_bind and IPv6
From: Vincent Bernat @ 2011-12-16 6:24 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: netdev, davem, yoshfuji
In-Reply-To: <CAHo-OoxrYpFMBVfriB7HhL-BpMXJgCe1-mL4L8UpsDQJifMZvQ@mail.gmail.com>
OoO En ce milieu de nuit étoilée du vendredi 16 décembre 2011, vers
04:58, Maciej Żenczykowski <zenczykowski@gmail.com> disait :
> why not simply use the IP_TRANSPARENT or IP_FREEBIND socket options?
Because this requires modifying each affected software. This can be
difficult if you don't have the source code available.
--
Vincent Bernat ☯ http://vincent.bernat.im
panic("Detected a card I can't drive - whoops\n");
2.2.16 /usr/src/linux/drivers/net/daynaport.c
^ permalink raw reply
* Re: pull request: wireless 2011-12-15
From: Rafał Miłecki @ 2011-12-16 6:40 UTC (permalink / raw)
To: John W. Linville, Arend Van Spriel
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20111215213822.GB2561-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
W dniu 15 grudnia 2011 22:38 użytkownik John W. Linville
<linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> napisał:
> On Thu, Dec 15, 2011 at 09:04:29PM +0100, Rafał Miłecki wrote:
>> 2011/12/15 John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>:
>> > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e
>> >
>> > Dave,
>> >
>> > Here are a few more fixes intended for the 3.2 release. They are
>> > all small and narrowly focused.
>>
>> John, I've made a mistake and didn't use [PATCH 3.2] header to make it
>> clean my patch is fix. Could you take a look at
>> [PATCH] bcma: support for suspend and resume
>> please?
>>
>> It's not one-liner, but fixes lock ups, which I believe - we really
>> want to avoid.
>
> It's late in the release cycle, and Dave specifically asked me to slow down.
>
> Are these suspend/resume lockups a regression? Or have they always
> been there? Do they happen to everyone?
The bug is present since first days of bcma. That's why I even decided
to add stable to CC.
Personally I've tested that only on 1 machine (I don't have more
suspendable machines with mini PCIe slot). However all Macbook 8.1/8.2
users have to remove b43 & bcma before suspending [0], they complain
about that since ever.
Arend: I know you're also complaining for suspend in bcma. Can you
comment on this?
[0] http://ubuntuforums.org/showthread.php?t=1695746
--
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Bonding-devel] ethernet bonding + VLAN: additional VLAN tag in tcpdump
From: Thomas De Schampheleire @ 2011-12-16 6:47 UTC (permalink / raw)
To: Jiri Pirko
Cc: Nicolas de Pesloüan, bonding-devel, tcpdump-workers,
Ronny Meeus, netdev@vger.kernel.org
In-Reply-To: <CAAXf6LXOEpDNf-abqZ_FCJ4G85s-domOHLzH0ur+F77gOvO8EA@mail.gmail.com>
On Mon, Dec 5, 2011 at 10:50 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi,
>
> On Wed, Nov 30, 2011 at 10:06 AM, Thomas De Schampheleire
> <patrickdepinguin@gmail.com> wrote:
>> On Wed, Nov 30, 2011 at 8:52 AM, Jiri Pirko <jpirko@redhat.com> wrote:
>>> Tue, Nov 29, 2011 at 09:35:00PM CET, nicolas.2p.debian@gmail.com wrote:
>>>>Le 29/11/2011 14:38, Thomas De Schampheleire a écrit :
>>>>>Hi,
>>>>>
>>>>>I'm seeing incorrect tcpdump output in the following scenario:
>>>>>
>>>>>* ethernet bonding enabled in the kernel, and a single network
>>>>>interface (eth0) added as slave
>>>>>* bonding mode was set to broadcast, but I don't think this matters
>>>>>* VLAN added to the bond0 network interface
>>>>>* ip address set on the vlan interface (bond0.1234)
>>>>>* tcpdump capturing full packets (-xx or even -x) on the eth0 interface
>>>>>
>>>>>Then, when pinging from another machine to this ip address, the ping
>>>>>reply packets shown by tcpdump incorrectly have a double VLAN tag.
>>>>>However, what really appears on the wire is correct: a single VLAN
>>>>>tag.
>>>>
>>>>Copied netdev, because bonding and vlan developers are there.
>>>>
>>>>Jiri, don't you think this might be related to the work you have done
>>>>to make non-hw-accel rx path similar to hw-accel?
>>>
>>> I do not think so. The changes you are reffering to are unrelated to tx
>>> path (where this issue has most probably roots in)
>>>
>>>>
>>>> Nicolas.
>>>>
>>>>>
>>>>>Here is the output from tcpdump:
>>>>># /tmp/tcpdump -i eth0 -xx
>>>
>>> What hw is this?
>>
>> This is on a Freescale P4080 DPA mac (fsl,p4080-fman-1g-mac).
>>
>>>
>>>>>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>>>>>listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>>>>>01:04:04.607880 IP 192.168.1.2> 192.168.1.1: ICMP echo request, id 26933, seq 4
>>>>>16, length 64
>>>>> 0x0000: 0600 0000 0020 0600 0000 0020 8100 0ffe
>>>>> 0x0010: 0800 4500 0054 0000 4000 4001 b755 c0a8
>>>>> 0x0020: 0102 c0a8 0101 0800 98d7 6935 01a0 e528
>>>>> 0x0030: 0f2a 0000 0000 0000 0000 0000 0000 0000
>>>>> 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000
>>>>> 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000
>>>>> 0x0060: 0000 0000 0000
>>>>>01:04:04.607889 IP 192.168.1.1> 192.168.1.2: ICMP echo reply, id 26933, seq 416
>>>>>, length 64
>>>>> 0x0000: 0600 0000 0020 0600 0000 0020 8100 0ffe
>>>>> 0x0010: 8100 0ffe 0800 4500 0054 cc07 0000 4001<--------
>>>>>extra VLAN header at 0x10
>>>>> 0x0020: 2b4e c0a8 0101 c0a8 0102 0000 a0d7 6935
>>>>> 0x0030: 01a0 e528 0f2a 0000 0000 0000 0000 0000
>>>>> 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000
>>>>> 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000
>>>>> 0x0060: 0000 0000 0000 0000 0000
>>>>>
>>>>>
>>>>>Initial debugging showed that the addition of the extra VLAN header
>>>>>takes place in function pcap_read_linux_mmap() of libpcap, in the
>>>>>following snippet:
>>>>>
>>>>>#ifdef HAVE_TPACKET2
>>>>> if (handle->md.tp_version == TPACKET_V2&& h.h2->tp_vlan_tci&&
>>>>> tp_snaplen>= 2 * ETH_ALEN) {
>>>>> struct vlan_tag *tag;
>>>>>
>>>>> bp -= VLAN_TAG_LEN;
>>>>> memmove(bp, bp + VLAN_TAG_LEN, 2 * ETH_ALEN);
>>>>>
>>>>> tag = (struct vlan_tag *)(bp + 2 * ETH_ALEN);
>>>>> tag->vlan_tpid = htons(ETH_P_8021Q);
>>>>> tag->vlan_tci = htons(h.h2->tp_vlan_tci);
>>>>>
>>>>> pcaphdr.caplen += VLAN_TAG_LEN;
>>>>> pcaphdr.len += VLAN_TAG_LEN;
>>>>> }
>>>>>#endif
>>>
>>> I haven't look into this code yet, but where's the code which does the
>>> first header inclusion?
>>
>> I would assume this is done by the VLAN layer. This is a ping reply
>> originating from the icmp code, passing down to the vlan layer, then
>> to the ethernet bonding layer, and then to the hardware. But before
>> this is passed to hardware, libpcap captures the packet.
>>
>> I haven't debugged that part, though, so I can't give you a direct
>> pointer to the code that does it.
>>
>>>
>>>
>>>>>
>>>>>Upon entry of this code, the packet in bp already contains a VLAN header.
>>>>>
>>>>>It's unclear to me where the problem lies exactly. I suspect it has
>>>>>something to do with the ethernet bonding layer indicating it has
>>>>>hardware vlan tagging support, while it does already fill in the vlan
>>>>>header, and libpcap being confused by this.
>>>>>
>>>>>As mentioned previously, the packets on the wire are correct, and this
>>>>>is purely a capturing problem.
>>>>>
>>
>
> Does anyone have an idea on how this is supposed to work and why the
> extra header gets inserted?
Bump.
I would expect that this problem is independent on the hardware, and
therefore should be reproducible by others as well, pretty easily.
Thanks,
Thomas
^ permalink raw reply
* Re: nonlocal_bind and IPv6
From: YOSHIFUJI Hideaki @ 2011-12-16 6:46 UTC (permalink / raw)
To: Vincent Bernat; +Cc: netdev, davem, YOSHIFUJI Hideaki
In-Reply-To: <1323879648-419-1-git-send-email-bernat@luffy.cx>
Have you tried to send packets from the application on node with
local_bind enabled (without the address the application binds)?
Vincent Bernat wrote:
> This is a second tentative to port ip_nonlocal_bind to IPv6. The two
> patches are independant. The first patch enables
> net.ipv6.ip_nonlocal_bind and is "namespace aware". The second patch
> modifies net.ipv4.ip_nonlocal_bind to also be "namespace aware". I
> don't know if this is something important.
>
> I did not test the SCTP part of the second patch (but it compiles).
>
> Documentation/networking/ip-sysctl.txt | 5 +++++
> include/net/netns/ipv4.h | 1 +
> include/net/netns/ipv6.h | 1 +
> net/ipv4/af_inet.c | 6 +-----
> net/ipv4/ping.c | 2 +-
> net/ipv4/sysctl_net_ipv4.c | 16 +++++++++-------
> net/ipv6/af_inet6.c | 6 ++++--
> net/ipv6/sysctl_net_ipv6.c | 8 ++++++++
> net/sctp/protocol.c | 2 +-
> 9 files changed, 31 insertions(+), 16 deletions(-)
>
> --
> 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
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