Netdev List
 help / color / mirror / Atom feed
* Re: [v2 Patch 1/2] s2io: add dynamic LRO disable support
From: Cong Wang @ 2010-06-15  8:26 UTC (permalink / raw)
  To: Ramkrishna Vepa
  Cc: Ben Hutchings, netdev@vger.kernel.org, nhorman@redhat.com,
	sgruszka@redhat.com, herbert.xu@redhat.com, davem@davemloft.net
In-Reply-To: <FCA91A92EE52B041906A0358FC28FCC38EF13E71B8@FRE1EXCH02.hq.exar.com>

On 06/10/10 02:52, Ramkrishna Vepa wrote:
>> On Wed, 2010-06-09 at 06:05 -0400, Amerigo Wang wrote:
>> [...]
>>> +static int s2io_ethtool_set_flags(struct net_device *dev, u32 data)
>>> +{
>>> +   struct s2io_nic *sp = netdev_priv(dev);
>>> +   int rc = 0;
>>> +   int changed = 0;
>>> +
>>> +   if (data&  ETH_FLAG_LRO) {
>>> +           if (lro_enable) {
>>> +                   if (!(dev->features&  NETIF_F_LRO)) {
>>> +                           dev->features |= NETIF_F_LRO;
>>> +                           changed = 1;
>>> +                   }
>>> +           } else
>>> +                   rc = -EINVAL;
>>> +   } else if (dev->features&  NETIF_F_LRO) {
>>> +           dev->features&= ~NETIF_F_LRO;
>>> +           changed = 1;
>>> +   }
>>> +
>>> +   if (changed&&  netif_running(dev)) {
>>> +           s2io_stop_all_tx_queue(sp);
>>> +           s2io_card_down(sp);
>>> +           sp->lro = dev->features&  NETIF_F_LRO;
>>> +           rc = s2io_card_up(sp);
>>> +           s2io_start_all_tx_queue(sp);
>> [...]
>>
>> Is it safe to call s2io_start_all_tx_queue() if s2io_card_up() failed?
> Ben,
> Good point. If s2io_card_up() fails the chip will not be accessed, so it's safe but all transmit skbs will be freed without the user knowing the reason for failing to transmit or receive for that matter.  The other option is to return with a failure and get the watchdog timer reset the adapter.
>

(Sorry for the delay, I was on vacation.)

So it seems the latter option is better?

Thanks.

^ permalink raw reply

* Re: [PATCH 8/8] af_unix: Allow connecting to sockets in other network namespaces.
From: Pavel Emelyanov @ 2010-06-15  8:12 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Linux Containers, Serge Hallyn, netdev-u79uwXL29TY76Z2rM5mHXA,
	David Miller
In-Reply-To: <m11vcbgimj.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>

> [snip]
> 
> Signed-off-by: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>

Acked-by: Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>

^ permalink raw reply

* Re: [PATCH 7/8] af_unix: Allow credentials to work across user and pid namespaces.
From: Pavel Emelyanov @ 2010-06-15  8:11 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Linux Containers, Serge Hallyn, netdev-u79uwXL29TY76Z2rM5mHXA,
	David Miller
In-Reply-To: <m17hm3giom.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>

On 06/13/2010 05:34 PM, Eric W. Biederman wrote:
> 
> In unix_skb_parms store pointers to struct pid and struct cred instead
> of raw uid, gid, and pid values, then translate the credentials on
> reception into values that are meaningful in the receiving processes
> namespaces.
> 
> Signed-off-by: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>

Acked-by: Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>

^ permalink raw reply

* Re: [PATCH 6/8] scm: Capture the full credentials of the scm sender.
From: Pavel Emelyanov @ 2010-06-15  8:08 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: David Miller, Serge Hallyn, Linux Containers, Daniel Lezcano,
	netdev
In-Reply-To: <m1d3vvgirx.fsf@fess.ebiederm.org>

> +static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
> +{
> +	put_pid(scm->pid);
> +	scm->pid  = NULL;
> +
> +	if (scm->cred)
> +		put_cred(scm->cred);
> +	scm->cred = NULL;
> +}
> +
>  static __inline__ void scm_destroy(struct scm_cookie *scm)
>  {
> +	scm_destroy_cred(scm);
>  	if (scm && scm->fp)
>  		__scm_destroy(scm);
>  }

I'm a bit worried by the "if (scm" check. It makes me think scm can
be NULL here and thus scm_destroy_cred can oops.

^ permalink raw reply

* Re: [PATCH 5/8] af_netlink: Add needed scm_destroy after scm_send.
From: Pavel Emelyanov @ 2010-06-15  8:06 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: David Miller, Serge Hallyn, Linux Containers, Daniel Lezcano,
	netdev
In-Reply-To: <m1ljajgiud.fsf@fess.ebiederm.org>

On 06/13/2010 05:31 PM, Eric W. Biederman wrote:
> 
> scm_send occasionally allocates state in the scm_cookie, so I have
> modified netlink_sendmsg to guarantee that when scm_send succeeds
> scm_destory will be called to free that state.
> 
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>

Acked-by: Pavel Emelyanov <xemul@openvz.org>

^ permalink raw reply

* Re: [PATCH 4/8] af_unix: Allow SO_PEERCRED to work across namespaces.
From: Pavel Emelyanov @ 2010-06-15  8:04 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: David Miller, Serge Hallyn, Linux Containers, Daniel Lezcano,
	netdev
In-Reply-To: <m1r5kbgivt.fsf@fess.ebiederm.org>

On 06/13/2010 05:30 PM, Eric W. Biederman wrote:
> 
> Use struct pid and struct cred to store the peer credentials on struct
> sock.  This gives enough information to convert the peer credential
> information to a value relative to whatever namespace the socket is in
> at the time.
> 
> This removes nasty surprises when using SO_PEERCRED on socket
> connetions where the processes on either side are in different pid and
> user namespaces.
> 
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>

Acked-by: Pavel Emelyanov <xemul@openvz.org>

^ permalink raw reply

* Re: [PATCH 3/8] sock: Introduce cred_to_ucred
From: Pavel Emelyanov @ 2010-06-15  8:03 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: David Miller, Serge Hallyn, Linux Containers, Daniel Lezcano,
	netdev
In-Reply-To: <m139wrhxic.fsf@fess.ebiederm.org>

On 06/13/2010 05:28 PM, Eric W. Biederman wrote:
> 
> To keep the coming code clear and to allow both the sock
> code and the scm code to share the logic introduce a
> fuction to translate from struct cred to struct ucred.
> 
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>

Acked-by: Pavel Emelyanov <xemul@openvz.org>

^ permalink raw reply

* Re: [PATCH 2/8] user_ns: Introduce user_nsmap_uid and user_ns_map_gid.
From: Pavel Emelyanov @ 2010-06-15  8:02 UTC (permalink / raw)
  To: Eric W. Biederman, David Miller
  Cc: Linux Containers, Serge Hallyn, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <m17hm3hxjw.fsf_-_-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>

On 06/13/2010 05:28 PM, Eric W. Biederman wrote:
> 
> Define what happens when a we view a uid from one user_namespace
> in another user_namepece.
> 
> - If the user namespaces are the same no mapping is necessary.
> 
> - For most cases of difference use overflowuid and overflowgid,
>   the uid and gid currently used for 16bit apis when we have a 32bit uid
>   that does fit in 16bits.  Effectively the situation is the same,
>   we want to return a uid or gid that is not assigned to any user.
> 
> - For the case when we happen to be mapping the uid or gid of the
>   creator of the target user namespace use uid 0 and gid as confusing
>   that user with root is not a problem.
> 
> Signed-off-by: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>

I suppose this one should go via Andrew, not Dave.

Anyway, Acked-by: Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>

^ permalink raw reply

* Re: [PATCH 1/8] scm: Reorder scm_cookie.
From: Pavel Emelyanov @ 2010-06-15  8:00 UTC (permalink / raw)
  To: Eric W. Biederman, David Miller
  Cc: Serge Hallyn, Linux Containers, Daniel Lezcano, netdev
In-Reply-To: <m1d3vvhxlj.fsf@fess.ebiederm.org>

On 06/13/2010 05:27 PM, Eric W. Biederman wrote:
> 
> Reorder the fields in scm_cookie so they pack better on 64bit.
> 
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>

Acked-by: Pavel Emelyanov <xemul@openvz.org>

^ permalink raw reply

* Re: [PATCH net-next-2.6] loopback: Implement 64bit stats on 32bit arches
From: Eric Dumazet @ 2010-06-15  7:23 UTC (permalink / raw)
  To: Nick Piggin; +Cc: David Miller, netdev, bhutchings
In-Reply-To: <20100615064923.GF6138@laptop>

Le mardi 15 juin 2010 à 16:49 +1000, Nick Piggin a écrit :
> On Mon, Jun 14, 2010 at 11:14:12PM -0700, David Miller wrote:
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Mon, 14 Jun 2010 17:59:22 +0200
> > 
> > > Uses a seqcount_t to synchronize stat producer and consumer, for packets
> > > and bytes counter, now u64 types.
> > > 
> > > (dropped counter being rarely used, stay a native "unsigned long" type)
> > > 
> > > No noticeable performance impact on x86, as it only adds two increments
> > > per frame. It might be more expensive on arches where smp_wmb() is not
> > > free.
> > > 
> > > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > 
> > Applied, but I suspect we might end up eventually needing to
> > abstract this kind of technique in a common place so other
> > spots can use it.
> 

David, I was planning adding similar stuff for SNMP, xt_RATEEST and txq
accounting, so yes, I'll probably move helpers to a common include file.

This first patch was a first shot to introduce the ground.

> Check i_size stuff in include/linux/fs.h if you consider doing this.

Yes, I was aware of this stuff.

> And keep preempt in mind too. I assume you can't be preempted at this
> point, but if you're prone to change the locking, it might be worth
> the (small) cost of doing explicit preempt_disable() (and maybe to
> help the sanity of the -rt guys too).
> 

Yes, we cannot be preempted at this point, as ndo_start_xmit() handlers
are called with BH disabled (there is a comment for this assertion in
front of loopback_xmit())

dev_queue_xmit() 
  rcu_read_lock_bh();
  ...
  ndo_start_xmit();

I'll take care of preempt status for following patches, but I suspect
its more a BH enable/disable question in network stack anyway.

Thanks !



^ permalink raw reply

* ftp on udp and tcp .
From: ratheesh k @ 2010-06-15  7:20 UTC (permalink / raw)
  To: netdev, linux-net

Hi ,

       what is real advantage of UDP over TCP / TCP over UDP .  If i
put the question in a different way - if run ftp application on UDP
and TCP , what is the real difference / advantage  ??

Thanks,
Ratheesh

^ permalink raw reply

* Re: [PATCH] net: IP_NODEFRAG option for IPv4 socket
From: Eric Dumazet @ 2010-06-15  7:13 UTC (permalink / raw)
  To: Jiri Olsa
  Cc: Jan Engelhardt, Patrick McHardy, netdev,
	Netfilter Developer Mailing List
In-Reply-To: <20100615065335.GA8840@jolsa.Belkin>

Le mardi 15 juin 2010 à 08:53 +0200, Jiri Olsa a écrit :
> hi,
> 
> I prepared the patch implementing IP_NODEFRAG option for IPv4 socket.
> The reason is, there's no other way to send out the packet with user
> customized header of the reassembly part.
> 

Obviously, you need to update documentation and man pages as well.

MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
M:	Michael Kerrisk <mtk.manpages@gmail.com>
W:	http://www.kernel.org/doc/man-pages
L:	linux-man@vger.kernel.org
S:	Maintained


> wbr,
> jirka
> 
> 
> Signed-off-by: Jiri Olsa <jolsa@redhat.com>
> ---
> diff --git a/include/linux/in.h b/include/linux/in.h
> index 583c76f..41d88a4 100644
> --- a/include/linux/in.h
> +++ b/include/linux/in.h
> @@ -85,6 +85,7 @@ struct in_addr {
>  #define IP_RECVORIGDSTADDR   IP_ORIGDSTADDR
>  
>  #define IP_MINTTL       21
> +#define IP_NODEFRAG     22
>  
>  /* IP_MTU_DISCOVER values */
>  #define IP_PMTUDISC_DONT		0	/* Never send DF frames */
> diff --git a/include/net/inet_sock.h b/include/net/inet_sock.h
> index 1653de5..1989cfd 100644
> --- a/include/net/inet_sock.h
> +++ b/include/net/inet_sock.h
> @@ -137,7 +137,8 @@ struct inet_sock {
>  				hdrincl:1,
>  				mc_loop:1,
>  				transparent:1,
> -				mc_all:1;
> +				mc_all:1,
> +				nodefrag:1;
>  	int			mc_index;
>  	__be32			mc_addr;
>  	struct ip_mc_socklist	*mc_list;
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index 551ce56..84d2c8e 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -355,6 +355,8 @@ lookup_protocol:
>  	inet = inet_sk(sk);
>  	inet->is_icsk = (INET_PROTOSW_ICSK & answer_flags) != 0;
>  
> +	inet->nodefrag = 0;
> +

Hmm... what about cloning ?

>  	if (SOCK_RAW == sock->type) {
>  		inet->inet_num = protocol;
>  		if (IPPROTO_RAW == protocol)
> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> index ce23178..d8196e1 100644
> --- a/net/ipv4/ip_sockglue.c
> +++ b/net/ipv4/ip_sockglue.c
> @@ -449,7 +449,7 @@ static int do_ip_setsockopt(struct sock *sk, int level,
>  			     (1<<IP_MTU_DISCOVER) | (1<<IP_RECVERR) |
>  			     (1<<IP_ROUTER_ALERT) | (1<<IP_FREEBIND) |
>  			     (1<<IP_PASSSEC) | (1<<IP_TRANSPARENT) |
> -			     (1<<IP_MINTTL))) ||
> +			     (1<<IP_MINTTL) | (1<<IP_NODEFRAG))) ||
>  	    optname == IP_MULTICAST_TTL ||
>  	    optname == IP_MULTICAST_ALL ||
>  	    optname == IP_MULTICAST_LOOP ||
> @@ -572,6 +572,13 @@ static int do_ip_setsockopt(struct sock *sk, int level,
>  		}
>  		inet->hdrincl = val ? 1 : 0;
>  		break;
> +	case IP_NODEFRAG:
> +		if (sk->sk_type != SOCK_RAW) {
> +			err = -ENOPROTOOPT;
> +			break;
> +		}
> +		inet->nodefrag = val ? 1 : 0;
> +		break;
>  	case IP_MTU_DISCOVER:
>  		if (val < IP_PMTUDISC_DONT || val > IP_PMTUDISC_PROBE)
>  			goto e_inval;
> diff --git a/net/ipv4/netfilter/nf_defrag_ipv4.c b/net/ipv4/netfilter/nf_defrag_ipv4.c
> index cb763ae..eab8de3 100644
> --- a/net/ipv4/netfilter/nf_defrag_ipv4.c
> +++ b/net/ipv4/netfilter/nf_defrag_ipv4.c
> @@ -66,6 +66,11 @@ static unsigned int ipv4_conntrack_defrag(unsigned int hooknum,
>  					  const struct net_device *out,
>  					  int (*okfn)(struct sk_buff *))
>  {
> +	struct inet_sock *inet = inet_sk(skb->sk);
> +
> +	if (inet && inet->nodefrag)
> +		return NF_ACCEPT;
> +
>  #if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
>  #if !defined(CONFIG_NF_NAT) && !defined(CONFIG_NF_NAT_MODULE)
>  	/* Previously seen (loopback)?  Ignore.  Do this before
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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

* [PATCH] net: IP_NODEFRAG option for IPv4 socket
From: Jiri Olsa @ 2010-06-15  6:53 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Patrick McHardy, netdev, Netfilter Developer Mailing List
In-Reply-To: <20100611131038.GB1739@jolsa.Belkin>

hi,

I prepared the patch implementing IP_NODEFRAG option for IPv4 socket.
The reason is, there's no other way to send out the packet with user
customized header of the reassembly part.

wbr,
jirka


Signed-off-by: Jiri Olsa <jolsa@redhat.com>
---
diff --git a/include/linux/in.h b/include/linux/in.h
index 583c76f..41d88a4 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -85,6 +85,7 @@ struct in_addr {
 #define IP_RECVORIGDSTADDR   IP_ORIGDSTADDR
 
 #define IP_MINTTL       21
+#define IP_NODEFRAG     22
 
 /* IP_MTU_DISCOVER values */
 #define IP_PMTUDISC_DONT		0	/* Never send DF frames */
diff --git a/include/net/inet_sock.h b/include/net/inet_sock.h
index 1653de5..1989cfd 100644
--- a/include/net/inet_sock.h
+++ b/include/net/inet_sock.h
@@ -137,7 +137,8 @@ struct inet_sock {
 				hdrincl:1,
 				mc_loop:1,
 				transparent:1,
-				mc_all:1;
+				mc_all:1,
+				nodefrag:1;
 	int			mc_index;
 	__be32			mc_addr;
 	struct ip_mc_socklist	*mc_list;
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 551ce56..84d2c8e 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -355,6 +355,8 @@ lookup_protocol:
 	inet = inet_sk(sk);
 	inet->is_icsk = (INET_PROTOSW_ICSK & answer_flags) != 0;
 
+	inet->nodefrag = 0;
+
 	if (SOCK_RAW == sock->type) {
 		inet->inet_num = protocol;
 		if (IPPROTO_RAW == protocol)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index ce23178..d8196e1 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -449,7 +449,7 @@ static int do_ip_setsockopt(struct sock *sk, int level,
 			     (1<<IP_MTU_DISCOVER) | (1<<IP_RECVERR) |
 			     (1<<IP_ROUTER_ALERT) | (1<<IP_FREEBIND) |
 			     (1<<IP_PASSSEC) | (1<<IP_TRANSPARENT) |
-			     (1<<IP_MINTTL))) ||
+			     (1<<IP_MINTTL) | (1<<IP_NODEFRAG))) ||
 	    optname == IP_MULTICAST_TTL ||
 	    optname == IP_MULTICAST_ALL ||
 	    optname == IP_MULTICAST_LOOP ||
@@ -572,6 +572,13 @@ static int do_ip_setsockopt(struct sock *sk, int level,
 		}
 		inet->hdrincl = val ? 1 : 0;
 		break;
+	case IP_NODEFRAG:
+		if (sk->sk_type != SOCK_RAW) {
+			err = -ENOPROTOOPT;
+			break;
+		}
+		inet->nodefrag = val ? 1 : 0;
+		break;
 	case IP_MTU_DISCOVER:
 		if (val < IP_PMTUDISC_DONT || val > IP_PMTUDISC_PROBE)
 			goto e_inval;
diff --git a/net/ipv4/netfilter/nf_defrag_ipv4.c b/net/ipv4/netfilter/nf_defrag_ipv4.c
index cb763ae..eab8de3 100644
--- a/net/ipv4/netfilter/nf_defrag_ipv4.c
+++ b/net/ipv4/netfilter/nf_defrag_ipv4.c
@@ -66,6 +66,11 @@ static unsigned int ipv4_conntrack_defrag(unsigned int hooknum,
 					  const struct net_device *out,
 					  int (*okfn)(struct sk_buff *))
 {
+	struct inet_sock *inet = inet_sk(skb->sk);
+
+	if (inet && inet->nodefrag)
+		return NF_ACCEPT;
+
 #if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
 #if !defined(CONFIG_NF_NAT) && !defined(CONFIG_NF_NAT_MODULE)
 	/* Previously seen (loopback)?  Ignore.  Do this before

^ permalink raw reply related

* Re: [PATCH net-next-2.6] loopback: Implement 64bit stats on 32bit arches
From: Nick Piggin @ 2010-06-15  6:49 UTC (permalink / raw)
  To: David Miller; +Cc: eric.dumazet, netdev, bhutchings
In-Reply-To: <20100614.231412.39191304.davem@davemloft.net>

On Mon, Jun 14, 2010 at 11:14:12PM -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 14 Jun 2010 17:59:22 +0200
> 
> > Uses a seqcount_t to synchronize stat producer and consumer, for packets
> > and bytes counter, now u64 types.
> > 
> > (dropped counter being rarely used, stay a native "unsigned long" type)
> > 
> > No noticeable performance impact on x86, as it only adds two increments
> > per frame. It might be more expensive on arches where smp_wmb() is not
> > free.
> > 
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> 
> Applied, but I suspect we might end up eventually needing to
> abstract this kind of technique in a common place so other
> spots can use it.

Check i_size stuff in include/linux/fs.h if you consider doing this.
And keep preempt in mind too. I assume you can't be preempted at this
point, but if you're prone to change the locking, it might be worth
the (small) cost of doing explicit preempt_disable() (and maybe to
help the sanity of the -rt guys too).


^ permalink raw reply

* Re: [net-next PATCH] bnx2x: Fix link problem with some DACs
From: David Miller @ 2010-06-15  6:25 UTC (permalink / raw)
  To: yanivr; +Cc: netdev, ole, eilong
In-Reply-To: <1276590163.13056.32.camel@lb-tlvb-yanivr.il.broadcom.com>

From: "Yaniv Rosner" <yanivr@broadcom.com>
Date: Tue, 15 Jun 2010 11:22:43 +0300

> Change 2wire transfer rate of SFP+ module EEPROM from 400Khz to 100Khz since some DACs(direct attached cables) do not work at 400Khz.
> 
> Reported-by: Krzysztof Oldzki <ole@ans.pl>
> Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>

Applied, thanks.

^ permalink raw reply

* [net-next PATCH] bnx2x: Fix link problem with some DACs
From: Yaniv Rosner @ 2010-06-15  8:22 UTC (permalink / raw)
  To: davem; +Cc: netdev, ole, eilong

Change 2wire transfer rate of SFP+ module EEPROM from 400Khz to 100Khz since some DACs(direct attached cables) do not work at 400Khz.

Reported-by: Krzysztof Oldzki <ole@ans.pl>
Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
diff --git a/drivers/net/bnx2x_link.c b/drivers/net/bnx2x_link.c
index ff70be8..0383e30 100644
--- a/drivers/net/bnx2x_link.c
+++ b/drivers/net/bnx2x_link.c
@@ -4266,14 +4266,16 @@ static u8 bnx2x_ext_phy_init(struct link_params *params, struct link_vars *vars)
 					       MDIO_PMA_REG_10G_CTRL2, 0x0008);
 			}
 
-			/* Set 2-wire transfer rate to 400Khz since 100Khz
-			is not operational */
+			/* Set 2-wire transfer rate of SFP+ module EEPROM
+			 * to 100Khz since some DACs(direct attached cables) do
+			 * not work at 400Khz.
+			 */
 			bnx2x_cl45_write(bp, params->port,
 				       ext_phy_type,
 				       ext_phy_addr,
 				       MDIO_PMA_DEVAD,
 				       MDIO_PMA_REG_8727_TWO_WIRE_SLAVE_ADDR,
-				       0xa101);
+				       0xa001);
 
 			/* Set TX PreEmphasis if needed */
 			if ((params->feature_config_flags &




^ permalink raw reply related

* udp: Add UFO to NETIF_F_SOFTWARE_GSO
From: Herbert Xu @ 2010-06-15  6:21 UTC (permalink / raw)
  To: David S. Miller, netdev

Hi:

udp: Add UFO to NETIF_F_SOFTWARE_GSO

This patch adds UFO to the list of GSO features with a software
fallback.  This allows UFO to be used even if the hardware does
not support it.

In particular, this allows us to test the UFO fallback, as it
has been reported to not work in some cases.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 40291f3..ea48a43 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -847,7 +847,8 @@ struct net_device {
 #define NETIF_F_FSO		(SKB_GSO_FCOE << NETIF_F_GSO_SHIFT)
 
 	/* List of features with software fallbacks. */
-#define NETIF_F_GSO_SOFTWARE	(NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6)
+#define NETIF_F_GSO_SOFTWARE	(NETIF_F_TSO | NETIF_F_TSO_ECN | \
+				 NETIF_F_TSO6 | NETIF_F_UFO)
 
 
 #define NETIF_F_GEN_CSUM	(NETIF_F_NO_CSUM | NETIF_F_HW_CSUM)

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <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: [PATCH net-next-2.6] ipv6: avoid two atomics in ipv6_rthdr_rcv()
From: David Miller @ 2010-06-15  6:14 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev
In-Reply-To: <1276526367.2478.98.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Jun 2010 16:39:27 +0200

> Use __in6_dev_get() instead of in6_dev_get()/in6_dev_put()
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next-2.6] ipv6: RCU changes in ipv6_get_mtu() and ip6_dst_hoplimit()
From: David Miller @ 2010-06-15  6:14 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev
In-Reply-To: <1276526780.2478.101.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Jun 2010 16:46:20 +0200

> Use RCU to avoid atomic ops on idev refcnt in ipv6_get_mtu()
> and ip6_dst_hoplimit() 
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next-2.6] loopback: Implement 64bit stats on 32bit arches
From: David Miller @ 2010-06-15  6:14 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev, bhutchings
In-Reply-To: <1276531162.2478.121.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 Jun 2010 17:59:22 +0200

> Uses a seqcount_t to synchronize stat producer and consumer, for packets
> and bytes counter, now u64 types.
> 
> (dropped counter being rarely used, stay a native "unsigned long" type)
> 
> No noticeable performance impact on x86, as it only adds two increments
> per frame. It might be more expensive on arches where smp_wmb() is not
> free.
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied, but I suspect we might end up eventually needing to
abstract this kind of technique in a common place so other
spots can use it.

^ permalink raw reply

* Re: [PATCH] ethtool: Revert incorrect indentation changes
From: David Miller @ 2010-06-15  6:13 UTC (permalink / raw)
  To: bhutchings; +Cc: chavey, netdev
In-Reply-To: <1276541606.2074.12.camel@achroite.uk.solarflarecom.com>

From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 14 Jun 2010 19:53:26 +0100

> commit 97f8aefbbfb5aa5c9944e5fa8149f1fdaf71c7b6 "net: fix ethtool
> coding style errors and warnings" changed the indentation of several
> macro definitions in ethtool.h.  These definitions line up in the diff
> where there is an extra character at the start of each line, but not
> in the resulting file.
> 
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next-2.6] inetpeer: various changes
From: David Miller @ 2010-06-15  6:13 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev
In-Reply-To: <1276580121.30434.322.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 15 Jun 2010 07:35:21 +0200

> Try to reduce cache line contentions in peer management, to reduce IP
> defragmentation overhead.
> 
> - peer_fake_node is marked 'const' to make sure its not modified.
>   (tested with CONFIG_DEBUG_RODATA=y)
> 
> - Group variables in two structures to reduce number of dirtied cache
> lines. One named "peers" for avl tree root, its number of entries, and
> associated lock. (candidate for RCU conversion)
> 
> - A second one named "unused_peers" for unused list and its lock 
> 
> - Add a !list_empty() test in unlink_from_unused() to avoid taking lock
> when entry is not unused.
> 
> - Use atomic_dec_and_lock() in inet_putpeer() to avoid taking lock in
> some cases.
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next-2.6] ipv6: RCU changes in ipv6_get_mtu() and ip6_dst_hoplimit()
From: Eric Dumazet @ 2010-06-15  6:12 UTC (permalink / raw)
  To: YOSHIFUJI Hideaki; +Cc: David Miller, netdev, YOSHIFUJI Hideaki
In-Reply-To: <4C164840.5010900@yoshifuji.org>

Le mardi 15 juin 2010 à 00:18 +0900, YOSHIFUJI Hideaki a écrit :
> (2010/06/14 23:46), Eric Dumazet wrote:
> > Use RCU to avoid atomic ops on idev refcnt in ipv6_get_mtu()
> > and ip6_dst_hoplimit()
> >
> > Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
> Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> 
> --yoshfuji

Gah, sorry not having CC you at least for ipv6 stuff !

Thanks !




^ permalink raw reply

* RE: [net-next PATCH] bnx2x: Fix link problem with some DACs
From: Yaniv Rosner @ 2010-06-15  6:12 UTC (permalink / raw)
  To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20100614.230728.189694464.davem@davemloft.net>

Sure Dave,
I'll fix and send it again.

-----Original Message-----
From: David Miller [mailto:davem@davemloft.net] 
Sent: Tuesday, June 15, 2010 9:07 AM
To: Yaniv Rosner
Cc: netdev@vger.kernel.org
Subject: Re: [net-next PATCH] bnx2x: Fix link problem with some DACs

From: "Yaniv Rosner" <yanivr@broadcom.com>
Date: Mon, 14 Jun 2010 13:26:28 +0300

> -			/* Set 2-wire transfer rate to 400Khz since 100Khz
> -			is not operational */
> +			/* Set 2-wire transfer rate of SFP+ module EEPROM
> +			to 100Khz since some DACs(direct attached cables) do
> +			not work at 400Khz.*/

This is not the correct way to format a multi-line comment.
It should be:

			/* Set 2-wire transfer rate of SFP+ module EEPROM
			 * to 100Khz since some DACs(direct attached cables) do
			 * not work at 400Khz.
			 */



^ permalink raw reply

* Re: [net-next PATCH] bnx2x: Fix link problem with some DACs
From: David Miller @ 2010-06-15  6:07 UTC (permalink / raw)
  To: yanivr; +Cc: netdev
In-Reply-To: <1276511188.13056.26.camel@lb-tlvb-yanivr.il.broadcom.com>

From: "Yaniv Rosner" <yanivr@broadcom.com>
Date: Mon, 14 Jun 2010 13:26:28 +0300

> -			/* Set 2-wire transfer rate to 400Khz since 100Khz
> -			is not operational */
> +			/* Set 2-wire transfer rate of SFP+ module EEPROM
> +			to 100Khz since some DACs(direct attached cables) do
> +			not work at 400Khz.*/

This is not the correct way to format a multi-line comment.
It should be:

			/* Set 2-wire transfer rate of SFP+ module EEPROM
			 * to 100Khz since some DACs(direct attached cables) do
			 * not work at 400Khz.
			 */

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox