headers
David Miller | 1 Jul 2010 01:06
Favicon

Re: [net-next-2.6 PATCH 1/8] e1000e: cleanup ethtool loopback setup code

From: "Allan, Bruce W" <bruce.w.allan <at> intel.com>
Date: Wed, 30 Jun 2010 15:41:19 -0700

> I've been looking into your request number 2 above (as a reminder,
> it had to do with a patch I submitted that added a module parameter
> to e1000e in order to enable/disable Energy Efficient Ethernet for a
> particular type of adapter).
> 
> For this new ethtool feature bit/flag for EEE, would you prefer it be set via:
> 1) the generic parameter setting option (e.g. -s ethX [eee on|off]),
> 2) yet another new show/change option pair, or
> 3) a new option that can set this new feature and be expandable to future features that are likewise not
related to existing ethtool options (e.g. -F [eee on|off] [whizbang on|off])?
> 
> For #2 or #3, it makes sense to use ethtool_op_[g|s]et_flags with
> new ETH_FLAG_≤feature> and NETIF_F_≤feature> defines, but #1 can be
> implemented that way or by using remaining reserved elements of
> struct ethtool_cmd - if your preference is for #1, would you prefer
> it be implemented with the former or latter?

I only have strong feelings about the kernel side, and an ETH_FLAG_* seems
best for this since other devices will have this feature too.

I don't think overloading parts of ethtool_cmd is wise.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mitchell Erblich | 1 Jul 2010 01:10
Picon
Favicon

Re: TCP not triggering a fast retransmit?


On Jun 30, 2010, at 2:22 PM, David Miller wrote:

> From: Ben Hutchings <bhutchings <at> solarflare.com>
> Date: Wed, 30 Jun 2010 22:03:49 +0100
> 
>> In that packet capture I see TCP payload lengths which are 2, 3 and 4
>> times the usual MSS of 1448 bytes, which implies that GRO or LRO is in
>> use.  In RHEL 5.4 the TCP stack does not ACK often enough in this case
>> because it is missing this change:
>> 
>> commit ff9b5e0f08cb650d113eef0c654f931c0a7ae730
>> Author: Herbert Xu <herbert <at> gondor.apana.org.au>
>> Date:   Thu Aug 31 15:11:02 2006 -0700
>> 
>>    [TCP]: Fix rcv mss estimate for LRO
> 
> It certainly could be, I'll try make sure this gets rectified,
> thanks!
> --

Guys,

	I think you suggesting that:

__tcp_ack_snd_chk() within tcp_input.c needs: 
an ABC (Appropriate Byte Counting) Allman type check
where the frame rcv'd computed size is 2x or larger
(and no out of order queue) , then
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ivan Novick | 1 Jul 2010 02:27
Picon

Re: TCP not triggering a fast retransmit?

On Wed, Jun 30, 2010 at 2:03 PM, Ben Hutchings
<bhutchings <at> solarflare.com> wrote:
> On Wed, 2010-06-30 at 11:04 -0700, Ivan Novick wrote:
>> Hello all,
>>
>> Attached is a packet capture from my application that is running on
>> RedHat Enterprise Linux 5.4
>>
>> I am seeing a Retransmission timeout but I was hoping this case would
>> go into fast retransmit and not RTO.
>>
>> I am wondering why did the sender not send more data?  If the sender
>> was to send more data and extend the window then it would seem the
>> duplicate acks or SACKS should trigger fast retransmit.
> [...]
>
> In that packet capture I see TCP payload lengths which are 2, 3 and 4
> times the usual MSS of 1448 bytes, which implies that GRO or LRO is in
> use.  In RHEL 5.4 the TCP stack does not ACK often enough in this case
> because it is missing this change:
>
> commit ff9b5e0f08cb650d113eef0c654f931c0a7ae730
> Author: Herbert Xu <herbert <at> gondor.apana.org.au>
> Date:   Thu Aug 31 15:11:02 2006 -0700
>
>    [TCP]: Fix rcv mss estimate for LRO

Wow, Thanks! Is this the patch you are talking about:
http://www.mail-archive.com/netdev <at> vger.kernel.org/msg21151.html  ?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ben Hutchings | 1 Jul 2010 03:23

Re: TCP not triggering a fast retransmit?

On Wed, 2010-06-30 at 17:27 -0700, Ivan Novick wrote:
> On Wed, Jun 30, 2010 at 2:03 PM, Ben Hutchings
> <bhutchings <at> solarflare.com> wrote:
> > On Wed, 2010-06-30 at 11:04 -0700, Ivan Novick wrote:
> >> Hello all,
> >>
> >> Attached is a packet capture from my application that is running on
> >> RedHat Enterprise Linux 5.4
> >>
> >> I am seeing a Retransmission timeout but I was hoping this case would
> >> go into fast retransmit and not RTO.
> >>
> >> I am wondering why did the sender not send more data?  If the sender
> >> was to send more data and extend the window then it would seem the
> >> duplicate acks or SACKS should trigger fast retransmit.
> > [...]
> >
> > In that packet capture I see TCP payload lengths which are 2, 3 and 4
> > times the usual MSS of 1448 bytes, which implies that GRO or LRO is in
> > use.  In RHEL 5.4 the TCP stack does not ACK often enough in this case
> > because it is missing this change:
> >
> > commit ff9b5e0f08cb650d113eef0c654f931c0a7ae730
> > Author: Herbert Xu <herbert <at> gondor.apana.org.au>
> > Date:   Thu Aug 31 15:11:02 2006 -0700
> >
> >    [TCP]: Fix rcv mss estimate for LRO
> 
> Wow, Thanks! Is this the patch you are talking about:
> http://www.mail-archive.com/netdev <at> vger.kernel.org/msg21151.html  ?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sathya Perla | 1 Jul 2010 08:23
Favicon

Re: [net-next-2.6 PATCH] be2net: memory barrier fixes on IBM p7 platform

On Wed, 2010-06-30 at 13:27 -0700, David Miller wrote:
> > -
> > +	
> > +	rmb();
> 
> That first addition does nothing but add erroneous trailing
> whitespace.
> 
> You can physically see that something must be wrong here just by look
> at this patch chunk, please review things more thoroughly before
> submitting in the future.
> 
Will do, thanks.

___________________________________________________________________________________
This message, together with any attachment(s), contains confidential and proprietary information of
ServerEngines Corporation and is intended only for the designated recipient(s) named above. Any unauthorized
review, printing, retention, copying, disclosure or distribution is strictly prohibited.  If you are not the
intended recipient of this message, please immediately advise the sender by reply email message and
delete all copies of this message and any attachment(s). Thank you.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Stefan Assmann | 1 Jul 2010 08:37
Picon
Favicon

Re: [PATCH] igbvf: avoid name clash between PF and VF

On 30.06.2010 18:59, Casey Leedom wrote:
> | From: Stefan Assmann <sassmann <at> redhat.com>
> | Date: Wednesday, June 30, 2010 01:53 am
> | 
> | This is not a udev bug since udev doesn't create persistent rules for
> | VFs as their MAC address changes every reboot.
> | 
> | To avoid this problem we could change the kernel name for the VFs and
> | thus avoid confusion between VFs and PFs.
> | 
> | I've already discussed this with Alexander Duyck and Greg Rose, so far
> | they have no objection. However this problem appears for all drivers that
> | support PFs and VFs and thus the changes should be applied consistently
> | to all of these drivers.
> 
>   I'm not sure that this problem affects "all drivers which support PFs and VFs."  
> I think that you might mean "all drivers which support PFs and VFs with non-
> persistent MAC addresses for the VFs."  For instance, the MAC addresses 
> associated with the new cxgb4vf VFs are persistent so, from what I understand of 
> the scenario you outlined, I don't think that they would trigger the problem you 
> describe.  Please correct me if I've missed something.  Thanks.
> 
> Casey

You're correct, the problem shouldn't occur with cxgb4vf and therefore
this change shouldn't be necessary. However we might consider a
consistent naming scheme for VFs in all drivers. But I don't have a
strong opinion about this, either way would be fine by me.

  Stefan
(Continue reading)

Permalink | Reply | 2 comments |
headers
Simon Horman | 1 Jul 2010 09:07
Picon
Gravatar

Re: RFC: Allow 'ip' to run in daemon mode?

On Tue, Jun 29, 2010 at 08:34:41AM -0700, Ben Greear wrote:
> I'm considering modifying 'ip' to be able to run in daemon
> mode so that I can do lots of IP commands without having to
> pay the startup cost of iproute.
> 
> The -batch option almost works, but it's hard to programatically
> figure out failure codes.
> 
> I'm thinking about making these changes:
> 
> 1)  Move all of the error printing code into common methods (basically,
>    wrap printf).  In daemon mode this text can be sent back to the
>    calling process, and in normal mode, it will be printed to stdout/stderr
>    as it is currently.
> 
> 2)  Remove all or most calls to 'exit' and instead return error codes
>    to the calling logic.
> 
> 3)  Add ability to listen on a unix socket for commands, basically treat
>    them just like batch commands, one command per packet.
> 
> 4)  Return well formatted error code and text response to calling process
>    over the unix socket, maybe something like:
> 
> RV: [errno or equiv, zero for success]\n
> CMD: [ command string this relates to ]\n
> [ Optional free form text ]
> 
> 
> Does something like this have any chance of upstream inclusion?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Denis Kirjanov | 1 Jul 2010 11:39
Favicon

[PATCH] ll_temac: add error checking to DMA init path

Add error checking to DMA descriptor rings initialization code.

Signed-off-by: Denis Kirjanov <dkirjanov <at> kernel.org>
---
drivers/net/ll_temac_main.c |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index 52dcc84..7b12d0e 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
 <at>  <at>  -202,14 +202,29  <at>  <at>  static int temac_dma_bd_init(struct net_device *ndev)
 	int i;

 	lp->rx_skb = kzalloc(sizeof(*lp->rx_skb) * RX_BD_NUM, GFP_KERNEL);
+	if (!lp->rx_skb) {
+		dev_err(&ndev->dev,
+				"can't allocate memory for DMA RX buffer\n");
+		goto out;
+	}
 	/* allocate the tx and rx ring buffer descriptors. */
 	/* returns a virtual addres and a physical address. */
 	lp->tx_bd_v = dma_alloc_coherent(ndev->dev.parent,
 					 sizeof(*lp->tx_bd_v) * TX_BD_NUM,
 					 &lp->tx_bd_p, GFP_KERNEL);
+	if (!lp->tx_bd_v) {
+		dev_err(&ndev->dev,
+				"unable to allocate DMA TX buffer descriptors");
+		goto out;
+	}
(Continue reading)

Permalink | Reply | 1 comment |
headers
Denis Kirjanov | 1 Jul 2010 11:45
Favicon

[RESEND][PATCH] cxgb4: Use kfree_skb for skb pointers

Use kfree_skb for skb pointers

Acked-by: Dimitris Michailidis <dm <at> chelsio.com> 
Signed-off-by: Denis Kirjanov <dkirjanov <at> kernel.org>
---
drivers/net/cxgb4/l2t.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/cxgb4/l2t.c b/drivers/net/cxgb4/l2t.c
index 5b990d2..e8f0f55 100644
--- a/drivers/net/cxgb4/l2t.c
+++ b/drivers/net/cxgb4/l2t.c
 <at>  <at>  -314,7 +314,7  <at>  <at>  static void t4_l2e_free(struct l2t_entry *e)
 			struct sk_buff *skb = e->arpq_head;

 			e->arpq_head = skb->next;
-			kfree(skb);
+			kfree_skb(skb);
 		}
 		e->arpq_tail = NULL;
 	}
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |

Gmane