* Re: [PATCH ref0] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Po-Yu Chuang @ 2011-02-25 2:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, linux-kernel, bhutchings, joe, dilinger, mirqus, davem,
Po-Yu Chuang
In-Reply-To: <1298569685.2814.16.camel@edumazet-laptop>
Hi Eric,
On Fri, Feb 25, 2011 at 1:48 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 24 février 2011 à 18:39 +0100, Eric Dumazet a écrit :
>> Le jeudi 24 février 2011 à 17:29 +0800, Po-Yu Chuang a écrit :
>> > From: Po-Yu Chuang <ratbert@faraday-tech.com>
>> > +
>> > +static bool ftmac100_rx_packet(struct ftmac100 *priv, int *processed)
>> > +{
>> > + struct net_device *netdev = priv->netdev;
>> > + struct ftmac100_rxdes *rxdes;
>> > + struct sk_buff *skb;
>> > + struct page *page;
>> > + dma_addr_t map;
>> > + int length;
>> > +
>> > + rxdes = ftmac100_rx_locate_first_segment(priv);
>> > + if (!rxdes)
>> > + return false;
>> > +
>> > + if (unlikely(ftmac100_rx_packet_error(priv, rxdes))) {
>> > + ftmac100_rx_drop_packet(priv);
>> > + return true;
>> > + }
>> > +
>> > + /*
>> > + * It is impossible to get multi-segment packets
>> > + * because we always provide big enough receive buffers.
>> > + */
>> > + if (unlikely(!ftmac100_rxdes_last_segment(rxdes)))
>> > + BUG();
>> > +
>> > + /* start processing */
>> > + skb = netdev_alloc_skb_ip_align(netdev, ETH_HLEN);
>>
>> Oh I see... You should allocate a bigger head (say... 128 bytes)
>>
>> And copy in it up to 128 bytes of first part... this to avoid upper
>> stack to reallocate skb head (because IP/TCP processing need to get
>> their headers in skb head)
>
> Take a look at drivers/net/niu.c :
>
> #define RX_SKB_ALLOC_SIZE 128 + NET_IP_ALIGN
>
> static int niu_process_rx_pkt(...)
> {
> ...
> skb = netdev_alloc_skb(np->dev, RX_SKB_ALLOC_SIZE);
> ...
> while (1) {
> ...
> niu_rx_skb_append(skb, page, off, append_size);
> }
> }
Oh I got it.
I will try this and redo the benchmarking.
Thanks,
Po-Yu Chuang
^ permalink raw reply
* Re: [net-next-2.6 0/7][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2011-02-25 0:29 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips
In-Reply-To: <1298545109-8990-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 24 Feb 2011 02:58:22 -0800
> The following series contains jumbo frame support for X540 devices,
> comment cleanup/fixes for ixgbevf & igb, and the addition of Tx rate
> limiting feature for igb.
>
> The following are changes since commit 55ae22d08fc9b531bc8a88b7306004e7053bb425:
> Merge branch 'tipc-Feb23-2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/net-next-2.6
>
> and are available in the git repository at:
> master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6 master
Pulled, thanks a lot Jeff.
^ permalink raw reply
* Re: [Bugme-new] [Bug 29712] New: Bonding Driver(version : 3.5.0) - Problem with ARP monitoring in active backup mode
From: Andrew Morton @ 2011-02-24 22:51 UTC (permalink / raw)
To: harsha.r02; +Cc: bugzilla-daemon, bugme-daemon, netdev, Jay Vosburgh
In-Reply-To: <bug-29712-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 23 Feb 2011 10:41:34 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=29712
>
> Summary: Bonding Driver(version : 3.5.0) - Problem with ARP
> monitoring in active backup mode
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.32
That's a paleolithic kernel you have there. This problem might have
been fixed already. Can you test a more recent kernel?
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: harsha.r02@mphasis.com
> Regression: No
>
>
> We are facing an issue with arp_monitoring in active_backup mode when
> two network interfaces of two systems are connected back to back (point
> to point connected without switch connection) and bond is created on
> either systems with point-to-point connected interfaces as slaves.
>
> Steps to reproduce :
>
> 1. Initially the bond was created with two interfaces eth2 and eth3, having
> eth2 as primary
>
> # modprobe bonding primary=eth2 mode=1 arp_interval=500
> arp_ip_target=192.168.4.61
>
> # ifconfig bond0 192.168.2.63 netmask 255.255.255.0
>
> # ifenslave bond0 eth2 eth3
>
> # ifconfig bond0 up
>
> # cat /proc/net/bonding/bond0
>
> Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
>
> Bonding Mode: fault-tolerance (active-backup)
>
> Primary Slave: eth2
> Currently Active Slave: eth2
> MII Status: up
> MII Polling Interval (ms): 0
> Up Delay (ms): 0
> Down Delay (ms): 0
> ARP Polling Interval (ms): 500
> ARP IP target/s (n.n.n.n form): 192.168.4.61
>
> Slave Interface: eth2
> MII Status: up
> Link Failure Count: 1
> Permanent HW addr: 00:26:55:27:88:52
>
> Slave Interface: eth3
> MII Status: down
> Link Failure Count: 1
> Permanent HW addr: 00:26:55:27:88:54
>
> 2. The primary interface was made down, and fail over happened
>
> # ifconfig down
>
> # cat /proc/net/bonding/bond0
>
> Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
>
> Bonding Mode: fault-tolerance (active-backup)
> Primary Slave: eth2
> Currently Active Slave: eth3 <-- As expected -->
> MII Status: up
> MII Polling Interval (ms): 0
> Up Delay (ms): 0
> Down Delay (ms): 0
> ARP Polling Interval (ms): 500
> ARP IP target/s (n.n.n.n form): 192.168.4.61
>
> Slave Interface: eth2
> MII Status: down
> Link Failure Count: 2
> Permanent HW addr: 00:26:55:27:88:52
>
> Slave Interface: eth3
> MII Status: up
> Link Failure Count: 1
> Permanent HW addr: 00:26:55:27:88:54
>
> 3. The primary interface was brought up again and we did not see failover
> happening back to primary
>
> ned1g6:~# ifconfig eth2 up
>
> ned1g6:~# cat /proc/net/bonding/bond0
>
> Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
>
> Bonding Mode: fault-tolerance (active-backup)
> Primary Slave: eth2
> Currently Active Slave: eth3 <-- Ideally this should have been eth2 -->
> MII Status: up
> MII Polling Interval (ms): 0
> Up Delay (ms): 0
> Down Delay (ms): 0
> ARP Polling Interval (ms): 500
> ARP IP target/s (n.n.n.n form): 192.168.4.61
>
> Slave Interface: eth2
> MII Status: down
> Link Failure Count: 2
> Permanent HW addr: 00:26:55:27:88:52
>
> Slave Interface: eth3
> MII Status: up
> Link Failure Count: 1
> Permanent HW addr: 00:26:55:27:88:54
>
> The problem is that when the primary_slave comes up from the down state
> it won't get selected as the currently active slave for the bond.
>
> Best Regards,
> Harsha
^ permalink raw reply
* RE: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving peer configuration - ieee
From: Shmulik Ravid - Rabinovitz @ 2011-02-24 22:04 UTC (permalink / raw)
To: Ben Hutchings
Cc: davem@davemloft.net, John Fastabend, Eilon Greenstein,
netdev@vger.kernel.org
In-Reply-To: <1298576559.2613.40.camel@bwh-desktop>
> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: Thursday, February 24, 2011 9:43 PM
> To: Shmulik Ravid - Rabinovitz
> Cc: davem@davemloft.net; John Fastabend; Eilon Greenstein;
> netdev@vger.kernel.org
> Subject: Re: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving
> peer configuration - ieee
>
> On Thu, 2011-02-24 at 23:03 +0200, Shmulik Ravid wrote:
> > These 2 patches add the support for retrieving the remote or peer
> DCBX
> > configuration via dcbnl for embedded DCBX stacks. The peer
> configuration
> > is part of the DCBX MIB and is useful for debugging and diagnostics
> of
> > the overall DCB configuration. The first patch add this support for
> IEEE
> > 802.1Qaz standard the second patch add the same support for the older
> > CEE standard.
> >
> > Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
> > ---
> > include/linux/dcbnl.h | 38 ++++++++++++++++++++++++++
> > include/net/dcbnl.h | 5 +++
> > net/dcb/dcbnl.c | 71
> +++++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 114 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
> > index 4c5b26e..3102185 100644
> > --- a/include/linux/dcbnl.h
> > +++ b/include/linux/dcbnl.h
> > @@ -110,6 +110,22 @@ struct dcb_app {
> > __u16 protocol;
> > };
> >
> > +/* This structure contains the APP feature information sent by the
> peer.
> > + * It is used for both the IEEE 802.1Qaz and the CEE flavors.
> > + *
> > + * @willing: willing bit in the peer APP tlv
> > + * @error: error bit in the peer APP tlv
> > + * @app_count: The number of objects in the peer APP table.
> [...]
>
> It looks like this was supposed to be a kernel-doc comment, but it's
> not
> valid as such unless you start with:
>
> /**
> * struct dcb_peer_app_info - one-line description here
>
> Ben.
>
OK thanks, I'll fix this
Shmulik
^ permalink raw reply
* RE: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving peer configuration - ieee
From: Shmulik Ravid - Rabinovitz @ 2011-02-24 22:03 UTC (permalink / raw)
To: John Fastabend
Cc: davem@davemloft.net, Eilon Greenstein, netdev@vger.kernel.org
In-Reply-To: <4D66C186.7040409@intel.com>
> -----Original Message-----
> From: John Fastabend [mailto:john.r.fastabend@intel.com]
> Sent: Thursday, February 24, 2011 10:37 PM
> To: Shmulik Ravid - Rabinovitz
> Cc: davem@davemloft.net; Eilon Greenstein; netdev@vger.kernel.org
> Subject: Re: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving
> peer configuration - ieee
>
> On 2/24/2011 1:03 PM, Shmulik Ravid wrote:
> > These 2 patches add the support for retrieving the remote or peer
> DCBX
> > configuration via dcbnl for embedded DCBX stacks. The peer
> configuration
> > is part of the DCBX MIB and is useful for debugging and diagnostics
> of
> > the overall DCB configuration. The first patch add this support for
> IEEE
> > 802.1Qaz standard the second patch add the same support for the older
> > CEE standard.
> >
> > Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
> > ---
> > include/linux/dcbnl.h | 38 ++++++++++++++++++++++++++
> > include/net/dcbnl.h | 5 +++
> > net/dcb/dcbnl.c | 71
> +++++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 114 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
> > index 4c5b26e..3102185 100644
> > --- a/include/linux/dcbnl.h
> > +++ b/include/linux/dcbnl.h
> > @@ -110,6 +110,22 @@ struct dcb_app {
> > __u16 protocol;
> > };
> >
> > +/* This structure contains the APP feature information sent by the
> peer.
> > + * It is used for both the IEEE 802.1Qaz and the CEE flavors.
> > + *
> > + * @willing: willing bit in the peer APP tlv
> > + * @error: error bit in the peer APP tlv
> > + * @app_count: The number of objects in the peer APP table.
> > + *
> > + * In addition to this information the full peer APP tlv also
> contains
> > + * a table of 'app_count' APP objects defined above.
> > + */
> > +struct dcb_peer_app_info {
> > + __u8 willing;
> > + __u8 error;
> > + __u16 app_count;
> > +};
> > +
>
> The IEEE 802.1Qaz spec defines the APP TLV as informational
> so there are no willing or error bits in this case. See
> section D.2.12 of the 802.1Qaz draft.
>
> Can we drop these fields or do they have some other meaning
> here?
>
OK, They are part of the CEE APP tlv though.
I wanted to share this structure between the 802.1Qaz and CEE so
I'll have a single driver handler that retrieve the number of
peer apps. How about if we keep a single driver handler, but the
APP info will be exposed to the user only with the CEE flavor.
That is the PEER_APP attribute will be CEE specific ?
Shmulik
^ permalink raw reply
* [PATCH] ipv4: Rearrange how ip_route_newports() gets port keys.
From: David Miller @ 2011-02-24 21:42 UTC (permalink / raw)
To: netdev
ip_route_newports() is the only place in the entire kernel that
cares about the port members in the routing cache entry's lookup
flow key.
Therefore the only reason we store an entire flow inside of the
struct rtentry is for this one special case.
Rewrite ip_route_newports() such that:
1) The caller passes in the original port values, so we don't need
to use the rth->fl.fl_ip_{s,d}port values to remember them.
2) The lookup flow is constructed by hand instead of being copied
from the routing cache entry's flow.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/route.h | 19 +++++++++++--------
net/dccp/ipv4.c | 10 +++++++---
net/ipv4/tcp_ipv4.c | 6 +++++-
3 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/include/net/route.h b/include/net/route.h
index bf790c1..b3f89ad 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -200,16 +200,19 @@ static inline int ip_route_connect(struct rtable **rp, __be32 dst,
}
static inline int ip_route_newports(struct rtable **rp, u8 protocol,
+ __be16 orig_sport, __be16 orig_dport,
__be16 sport, __be16 dport, struct sock *sk)
{
- if (sport != (*rp)->fl.fl_ip_sport ||
- dport != (*rp)->fl.fl_ip_dport) {
- struct flowi fl;
-
- memcpy(&fl, &(*rp)->fl, sizeof(fl));
- fl.fl_ip_sport = sport;
- fl.fl_ip_dport = dport;
- fl.proto = protocol;
+ if (sport != orig_sport || dport != orig_dport) {
+ struct flowi fl = { .oif = (*rp)->fl.oif,
+ .mark = (*rp)->fl.mark,
+ .fl4_dst = (*rp)->fl.fl4_dst,
+ .fl4_src = (*rp)->fl.fl4_src,
+ .fl4_tos = (*rp)->fl.fl4_tos,
+ .proto = (*rp)->fl.proto,
+ .fl_ip_sport = sport,
+ .fl_ip_dport = dport };
+
if (inet_sk(sk)->transparent)
fl.flags |= FLOWI_FLAG_ANYSRC;
if (protocol == IPPROTO_TCP)
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 45a434f..9379891 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -43,6 +43,7 @@ int dccp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
struct inet_sock *inet = inet_sk(sk);
struct dccp_sock *dp = dccp_sk(sk);
const struct sockaddr_in *usin = (struct sockaddr_in *)uaddr;
+ __be16 orig_sport, orig_dport;
struct rtable *rt;
__be32 daddr, nexthop;
int tmp;
@@ -63,10 +64,12 @@ int dccp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
nexthop = inet->opt->faddr;
}
+ orig_sport = inet->inet_sport;
+ orig_dport = usin->sin_port;
tmp = ip_route_connect(&rt, nexthop, inet->inet_saddr,
RT_CONN_FLAGS(sk), sk->sk_bound_dev_if,
IPPROTO_DCCP,
- inet->inet_sport, usin->sin_port, sk, 1);
+ orig_sport, orig_dport, sk, 1);
if (tmp < 0)
return tmp;
@@ -99,8 +102,9 @@ int dccp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
if (err != 0)
goto failure;
- err = ip_route_newports(&rt, IPPROTO_DCCP, inet->inet_sport,
- inet->inet_dport, sk);
+ err = ip_route_newports(&rt, IPPROTO_DCCP,
+ orig_sport, orig_dport,
+ inet->inet_sport, inet->inet_dport, sk);
if (err != 0)
goto failure;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index ef5a90b..27a0cc8 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -149,6 +149,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
struct inet_sock *inet = inet_sk(sk);
struct tcp_sock *tp = tcp_sk(sk);
struct sockaddr_in *usin = (struct sockaddr_in *)uaddr;
+ __be16 orig_sport, orig_dport;
struct rtable *rt;
__be32 daddr, nexthop;
int tmp;
@@ -167,10 +168,12 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
nexthop = inet->opt->faddr;
}
+ orig_sport = inet->inet_sport;
+ orig_dport = usin->sin_port;
tmp = ip_route_connect(&rt, nexthop, inet->inet_saddr,
RT_CONN_FLAGS(sk), sk->sk_bound_dev_if,
IPPROTO_TCP,
- inet->inet_sport, usin->sin_port, sk, 1);
+ orig_sport, orig_dport, sk, 1);
if (tmp < 0) {
if (tmp == -ENETUNREACH)
IP_INC_STATS_BH(sock_net(sk), IPSTATS_MIB_OUTNOROUTES);
@@ -234,6 +237,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
goto failure;
err = ip_route_newports(&rt, IPPROTO_TCP,
+ orig_sport, orig_dport,
inet->inet_sport, inet->inet_dport, sk);
if (err)
goto failure;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving peer configuration - ieee
From: John Fastabend @ 2011-02-24 20:37 UTC (permalink / raw)
To: Shmulik Ravid
Cc: davem@davemloft.net, Eilon Greenstein, netdev@vger.kernel.org
In-Reply-To: <1298581410.8877.21.camel@lb-tlvb-shmulik.il.broadcom.com>
On 2/24/2011 1:03 PM, Shmulik Ravid wrote:
> These 2 patches add the support for retrieving the remote or peer DCBX
> configuration via dcbnl for embedded DCBX stacks. The peer configuration
> is part of the DCBX MIB and is useful for debugging and diagnostics of
> the overall DCB configuration. The first patch add this support for IEEE
> 802.1Qaz standard the second patch add the same support for the older
> CEE standard.
>
> Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
> ---
> include/linux/dcbnl.h | 38 ++++++++++++++++++++++++++
> include/net/dcbnl.h | 5 +++
> net/dcb/dcbnl.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 114 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
> index 4c5b26e..3102185 100644
> --- a/include/linux/dcbnl.h
> +++ b/include/linux/dcbnl.h
> @@ -110,6 +110,22 @@ struct dcb_app {
> __u16 protocol;
> };
>
> +/* This structure contains the APP feature information sent by the peer.
> + * It is used for both the IEEE 802.1Qaz and the CEE flavors.
> + *
> + * @willing: willing bit in the peer APP tlv
> + * @error: error bit in the peer APP tlv
> + * @app_count: The number of objects in the peer APP table.
> + *
> + * In addition to this information the full peer APP tlv also contains
> + * a table of 'app_count' APP objects defined above.
> + */
> +struct dcb_peer_app_info {
> + __u8 willing;
> + __u8 error;
> + __u16 app_count;
> +};
> +
The IEEE 802.1Qaz spec defines the APP TLV as informational
so there are no willing or error bits in this case. See
section D.2.12 of the 802.1Qaz draft.
Can we drop these fields or do they have some other meaning
here?
Thanks,
John.
^ permalink raw reply
* [RFC] be2net: add rxhash support
From: Eric Dumazet @ 2011-02-24 20:24 UTC (permalink / raw)
To: Ajit Khaparde; +Cc: netdev
In-Reply-To: <1298560543.2814.4.camel@edumazet-laptop>
Ajit, it seems be2net provides RSS hash value in rx compl descriptor ?
Could we feed skb->rxhash with it ?
Thanks !
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 0bdccb1..f2db5b2 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1038,6 +1038,9 @@ static void be_rx_compl_process(struct be_adapter *adapter,
skb->truesize = skb->len + sizeof(struct sk_buff);
skb->protocol = eth_type_trans(skb, adapter->netdev);
+ if (adapter->netdev->features & NETIF_F_RXHASH)
+ skb->rxhash = AMAP_GET_BITS(struct amap_eth_rx_compl, rsshash, rxcp);
+
vlanf = AMAP_GET_BITS(struct amap_eth_rx_compl, vtp, rxcp);
vtm = AMAP_GET_BITS(struct amap_eth_rx_compl, vtm, rxcp);
@@ -1099,6 +1102,9 @@ static void be_rx_compl_process_gro(struct be_adapter *adapter,
return;
}
+ if (adapter->netdev->features & NETIF_F_RXHASH)
+ skb->rxhash = AMAP_GET_BITS(struct amap_eth_rx_compl, rsshash, rxcp);
+
remaining = pkt_size;
for (i = 0, j = -1; i < num_rcvd; i++) {
page_info = get_rx_page_info(adapter, rxo, rxq_idx);
@@ -2618,6 +2624,7 @@ static void be_netdev_init(struct net_device *netdev)
NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_FILTER |
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
NETIF_F_GRO | NETIF_F_TSO6;
+ netdev->features |= NETIF_F_RXHASH;
netdev->vlan_features |= NETIF_F_SG | NETIF_F_TSO |
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
^ permalink raw reply related
* Re: via-rhine -- VT6105M and checksum offloading
From: David Miller @ 2011-02-24 20:23 UTC (permalink / raw)
To: bcrl; +Cc: netdev
In-Reply-To: <20110224185805.GI30393@kvack.org>
From: Benjamin LaHaise <bcrl@kvack.org>
Date: Thu, 24 Feb 2011 13:58:05 -0500
> I've recently noticed that one of the embedded systems I'm using (the
> PCEngines ALIXes) is becoming CPU bound under heavy network traffic.
> Upon investigation, it looks like the VT6105M isn't actually using the
> hardware checksum offloading support of the hardware. Are there any
> known reasons why this isn't enabled (hardware bugs?)? I'll test enabling
> it in the driver, but I figured it would be worth asking if this path
> has been explored already. Cheers,
As far as I can tell it was never attempted. So it should work.
If you do that, while you're here, you can make rhine_rx() take
a "napi" arg and make this driver use netif_gso_receive() too.
Don't forget to set NETIF_F_GRO or similar in netdev->flags during
probe, and also hookup the necessary ethtool hooks.
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving peer configuration - ieee
From: Ben Hutchings @ 2011-02-24 19:42 UTC (permalink / raw)
To: Shmulik Ravid; +Cc: davem, John Fastabend, Eilon Greenstein, netdev
In-Reply-To: <1298581410.8877.21.camel@lb-tlvb-shmulik.il.broadcom.com>
On Thu, 2011-02-24 at 23:03 +0200, Shmulik Ravid wrote:
> These 2 patches add the support for retrieving the remote or peer DCBX
> configuration via dcbnl for embedded DCBX stacks. The peer configuration
> is part of the DCBX MIB and is useful for debugging and diagnostics of
> the overall DCB configuration. The first patch add this support for IEEE
> 802.1Qaz standard the second patch add the same support for the older
> CEE standard.
>
> Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
> ---
> include/linux/dcbnl.h | 38 ++++++++++++++++++++++++++
> include/net/dcbnl.h | 5 +++
> net/dcb/dcbnl.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 114 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
> index 4c5b26e..3102185 100644
> --- a/include/linux/dcbnl.h
> +++ b/include/linux/dcbnl.h
> @@ -110,6 +110,22 @@ struct dcb_app {
> __u16 protocol;
> };
>
> +/* This structure contains the APP feature information sent by the peer.
> + * It is used for both the IEEE 802.1Qaz and the CEE flavors.
> + *
> + * @willing: willing bit in the peer APP tlv
> + * @error: error bit in the peer APP tlv
> + * @app_count: The number of objects in the peer APP table.
[...]
It looks like this was supposed to be a kernel-doc comment, but it's not
valid as such unless you start with:
/**
* struct dcb_peer_app_info - one-line description here
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] cxgb{3,4}: streamline Kconfig options
From: Dimitris Michailidis @ 2011-02-24 19:41 UTC (permalink / raw)
To: Jan Beulich; +Cc: David Miller, divy, linux-kbuild, netdev
In-Reply-To: <4D661E2702000078000336B5@vpn.id2.novell.com>
Jan Beulich wrote:
> As to that INET vs NET dependency - is it possible that the
> network drivers really just need NET, but the iSCSI ones need
> INET? In which case the only common dependency would be
> PCI - certainly not worth a custom helper option.
I see about a dozen network drivers that depend on INET. These may be the
result of cut&paste from other drivers' Kconfig entries rather than actual
dependencies. Also some of these drivers select or selected in the past
INET_LRO and that may have something to do with their INET dependency, not sure.
Reading the commit message that introduced CHELSIO_T3_DEPENDS, it talks of
hidden dependencies that select does not see. I am not sure which exactly
but since it's been a few years since that commit I'll try to see what the
situation is today without the *_DEPENDS symbols and let you know.
^ permalink raw reply
* via-rhine -- VT6105M and checksum offloading
From: Benjamin LaHaise @ 2011-02-24 18:58 UTC (permalink / raw)
To: netdev
Hi folks,
I've recently noticed that one of the embedded systems I'm using (the
PCEngines ALIXes) is becoming CPU bound under heavy network traffic.
Upon investigation, it looks like the VT6105M isn't actually using the
hardware checksum offloading support of the hardware. Are there any
known reasons why this isn't enabled (hardware bugs?)? I'll test enabling
it in the driver, but I figured it would be worth asking if this path
has been explored already. Cheers,
-ben
^ permalink raw reply
* Re: tun.c non formal header protocol?
From: Rémi Denis-Courmont @ 2011-02-24 19:04 UTC (permalink / raw)
To: Kfir Lavi; +Cc: netdev
In-Reply-To: <AANLkTikpkgiTRDJe0gxuXosp_uvg0gKM_c7GcvL+hhLm@mail.gmail.com>
Le jeudi 24 février 2011 20:37:32 Kfir Lavi, vous avez écrit :
> I would like to use custom protocol over tun/tap device.
Over TAP, you can only exchange Ethernet frames. However you can use whatever
network layer you like (so long as it has an Ethernet type associated).
Over TUN, you can exchange packets without any link layer header, for any
network layer protocol defined in Linux.
In principles, you can probably just use a (Ethernet) type that is not used by
any existing stack in the Linux kernel. But I don't see any point in doing so,
as the kernel will just drop the packets on the floor afterward.
> I'm grabbing packets, and changing them, to deliver via tap,
> to a listener that knows this custom protocol.
> The custom protocol is just wrapping the packet with another
> small header.
> Is it possible to move custom packets via tun.c ?
It's difficult to say without a clearer picture what you are trying to do.
--
Rémi Denis-Courmont
http://www.remlab.info/
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* [PATCH net-next-2.6 2/2] dcbnl: add support for retrieving peer configuration - cee
From: Shmulik Ravid @ 2011-02-24 21:03 UTC (permalink / raw)
To: davem; +Cc: John Fastabend, Eilon Greenstein, netdev
This patch adds the support for retrieving the remote or peer DCBX
configuration via dcbnl for embedded DCBX stacks supporting the CEE DCBX
standard.
Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
---
include/linux/dcbnl.h | 62 ++++++++++++++++++++++++++++++++++++++++++++++
include/net/dcbnl.h | 3 ++
net/dcb/dcbnl.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 131 insertions(+), 0 deletions(-)
diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
index 3102185..f937c75 100644
--- a/include/linux/dcbnl.h
+++ b/include/linux/dcbnl.h
@@ -87,6 +87,43 @@ struct ieee_pfc {
__u64 indications[IEEE_8021QAZ_MAX_TCS];
};
+/* CEE DCBX std supported values */
+#define CEE_DCBX_MAX_PGS 8
+#define CEE_DCBX_MAX_PRIO 8
+
+/* This structure contains the CEE Prioity-Group managed object
+ *
+ * @willing: willing bit in the PG tlv
+ * @error: error bit in the PG tlv
+ * @pg_en: enable bit of the PG feature
+ * @tcs_supported: number of traffic classes supported
+ * @pg_bw: bandwidth percentage for each priority group
+ * @prio_pg: priority to PG mapping indexed by priority
+ */
+struct cee_pg {
+ __u8 willing;
+ __u8 error;
+ __u8 pg_en;
+ __u8 tcs_supported;
+ __u8 pg_bw[CEE_DCBX_MAX_PGS];
+ __u8 prio_pg[CEE_DCBX_MAX_PGS];
+};
+
+/* This structure contains the PFC managed object
+ *
+ * @willing: willing bit in the PFC tlv
+ * @error: error bit in the PFC tlv
+ * @pfc_en: bitmap indicating pfc enabled traffic classes
+ * @tcs_supported: number of traffic classes supported
+ */
+struct cee_pfc {
+ __u8 willing;
+ __u8 error;
+ __u8 pfc_en;
+ __u8 tcs_supported;
+};
+
+
/* This structure contains the IEEE 802.1Qaz APP managed object. This
* object is also used for the CEE std as well. There is no difference
* between the objects.
@@ -160,6 +197,7 @@ struct dcbmsg {
* @DCB_CMD_SDCBX: set DCBX engine configuration
* @DCB_CMD_GFEATCFG: get DCBX features flags
* @DCB_CMD_SFEATCFG: set DCBX features negotiation flags
+ * @DCB_CMD_CEE_GET: get CEE aggregated configuration
*/
enum dcbnl_commands {
DCB_CMD_UNDEFINED,
@@ -202,6 +240,8 @@ enum dcbnl_commands {
DCB_CMD_GFEATCFG,
DCB_CMD_SFEATCFG,
+ DCB_CMD_CEE_GET,
+
__DCB_CMD_ENUM_MAX,
DCB_CMD_MAX = __DCB_CMD_ENUM_MAX - 1,
};
@@ -224,6 +264,7 @@ enum dcbnl_commands {
* @DCB_ATTR_IEEE: IEEE 802.1Qaz supported attributes (NLA_NESTED)
* @DCB_ATTR_DCBX: DCBX engine configuration in the device (NLA_U8)
* @DCB_ATTR_FEATCFG: DCBX features flags (NLA_NESTED)
+ * @DCB_ATTR_CEE: CEE std supported attributes (NLA_NESTED)
*/
enum dcbnl_attrs {
DCB_ATTR_UNDEFINED,
@@ -247,6 +288,9 @@ enum dcbnl_attrs {
DCB_ATTR_DCBX,
DCB_ATTR_FEATCFG,
+ /* CEE nested attributes */
+ DCB_ATTR_CEE,
+
__DCB_ATTR_ENUM_MAX,
DCB_ATTR_MAX = __DCB_ATTR_ENUM_MAX - 1,
};
@@ -281,6 +325,24 @@ enum ieee_attrs_app {
};
#define DCB_ATTR_IEEE_APP_MAX (__DCB_ATTR_IEEE_APP_MAX - 1)
+
+/**
+ * enum cee_attrs - CEE DCBX get attributes
+ *
+ * @DCB_ATTR_CEE_UNSPEC: unspecified
+ * @DCB_ATTR_CEE_PEER_PG: peer PG configuration - get only
+ * @DCB_ATTR_CEE_PEER_PFC: peer PFC configuration - get only
+ * @DCB_ATTR_CEE_PEER_APP: peer APP tlv - get only
+ */
+enum cee_attrs {
+ DCB_ATTR_CEE_UNSPEC,
+ DCB_ATTR_CEE_PEER_PG,
+ DCB_ATTR_CEE_PEER_PFC,
+ DCB_ATTR_CEE_PEER_APP,
+ __DCB_ATTR_CEE_MAX
+};
+#define DCB_ATTR_CEE_MAX (__DCB_ATTR_CEE_MAX - 1)
+
enum peer_app_attr {
DCB_ATTR_PEER_APP_UNSPEC,
DCB_ATTR_PEER_APP_INFO,
diff --git a/include/net/dcbnl.h b/include/net/dcbnl.h
index 739feb4..06227e83 100644
--- a/include/net/dcbnl.h
+++ b/include/net/dcbnl.h
@@ -83,6 +83,9 @@ struct dcbnl_rtnl_ops {
int (*peer_getappinfo)(struct net_device *, struct dcb_peer_app_info *);
int (*peer_getapptable)(struct net_device *, struct dcb_app *);
+ /* CEE peer */
+ int (*cee_peer_getpg) (struct net_device *, struct cee_pg *);
+ int (*cee_peer_getpfc) (struct net_device *, struct cee_pfc *);
};
#endif /* __NET_DCBNL_H__ */
diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
index 0eb7461..ea39e51 100644
--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -1512,6 +1512,68 @@ err:
return ret;
}
+/* Handle CEE DCBX GET commands. */
+static int dcbnl_cee_get(struct net_device *netdev, struct nlattr **tb,
+ u32 pid, u32 seq, u16 flags)
+{
+ struct sk_buff *skb;
+ struct nlmsghdr *nlh;
+ struct dcbmsg *dcb;
+ struct nlattr *cee;
+ const struct dcbnl_rtnl_ops *ops = netdev->dcbnl_ops;
+ int err;
+
+ if (!ops)
+ return -EOPNOTSUPP;
+
+ skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ if (!skb)
+ return -ENOBUFS;
+
+ nlh = NLMSG_NEW(skb, pid, seq, RTM_GETDCB, sizeof(*dcb), flags);
+
+ dcb = NLMSG_DATA(nlh);
+ dcb->dcb_family = AF_UNSPEC;
+ dcb->cmd = DCB_CMD_CEE_GET;
+
+ NLA_PUT_STRING(skb, DCB_ATTR_IFNAME, netdev->name);
+
+ cee = nla_nest_start(skb, DCB_ATTR_CEE);
+ if (!cee)
+ goto nla_put_failure;
+
+ /* get peer info if available */
+ if (ops->cee_peer_getpg) {
+ struct cee_pg pg;
+ err = ops->cee_peer_getpg(netdev, &pg);
+ if (!err)
+ NLA_PUT(skb, DCB_ATTR_CEE_PEER_PG, sizeof(pg), &pg);
+ }
+
+ if (ops->cee_peer_getpfc) {
+ struct cee_pfc pfc;
+ err = ops->cee_peer_getpfc(netdev, &pfc);
+ if (!err)
+ NLA_PUT(skb, DCB_ATTR_CEE_PEER_PFC, sizeof(pfc), &pfc);
+ }
+
+ if (ops->peer_getappinfo && ops->peer_getapptable) {
+ err = dcbnl_build_peer_app(netdev, skb, DCB_ATTR_CEE_PEER_APP);
+ if (err)
+ goto nla_put_failure;
+ }
+
+ nla_nest_end(skb, cee);
+ nlmsg_end(skb, nlh);
+
+ return rtnl_unicast(skb, &init_net, pid);
+nla_put_failure:
+ nlmsg_cancel(skb, nlh);
+nlmsg_failure:
+ kfree_skb(skb);
+ return -1;
+}
+
static int dcb_doit(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
{
struct net *net = sock_net(skb->sk);
@@ -1641,6 +1703,10 @@ static int dcb_doit(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
ret = dcbnl_setfeatcfg(netdev, tb, pid, nlh->nlmsg_seq,
nlh->nlmsg_flags);
goto out;
+ case DCB_CMD_CEE_GET:
+ ret = dcbnl_cee_get(netdev, tb, pid, nlh->nlmsg_seq,
+ nlh->nlmsg_flags);
+ goto out;
default:
goto errout;
}
--
1.7.3.5
^ permalink raw reply related
* [PATCH net-next-2.6 1/2] dcbnl: add support for retrieving peer configuration - ieee
From: Shmulik Ravid @ 2011-02-24 21:03 UTC (permalink / raw)
To: davem; +Cc: John Fastabend, Eilon Greenstein, netdev
These 2 patches add the support for retrieving the remote or peer DCBX
configuration via dcbnl for embedded DCBX stacks. The peer configuration
is part of the DCBX MIB and is useful for debugging and diagnostics of
the overall DCB configuration. The first patch add this support for IEEE
802.1Qaz standard the second patch add the same support for the older
CEE standard.
Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
---
include/linux/dcbnl.h | 38 ++++++++++++++++++++++++++
include/net/dcbnl.h | 5 +++
net/dcb/dcbnl.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 114 insertions(+), 0 deletions(-)
diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
index 4c5b26e..3102185 100644
--- a/include/linux/dcbnl.h
+++ b/include/linux/dcbnl.h
@@ -110,6 +110,22 @@ struct dcb_app {
__u16 protocol;
};
+/* This structure contains the APP feature information sent by the peer.
+ * It is used for both the IEEE 802.1Qaz and the CEE flavors.
+ *
+ * @willing: willing bit in the peer APP tlv
+ * @error: error bit in the peer APP tlv
+ * @app_count: The number of objects in the peer APP table.
+ *
+ * In addition to this information the full peer APP tlv also contains
+ * a table of 'app_count' APP objects defined above.
+ */
+struct dcb_peer_app_info {
+ __u8 willing;
+ __u8 error;
+ __u16 app_count;
+};
+
struct dcbmsg {
__u8 dcb_family;
__u8 cmd;
@@ -235,11 +251,25 @@ enum dcbnl_attrs {
DCB_ATTR_MAX = __DCB_ATTR_ENUM_MAX - 1,
};
+/**
+ * enum ieee_attrs - IEEE 802.1Qaz get/set attributes
+ *
+ * @DCB_ATTR_IEEE_UNSPEC: unspecified
+ * @DCB_ATTR_IEEE_ETS: negotiated ETS configuration
+ * @DCB_ATTR_IEEE_PFC: negotiated PFC configuration
+ * @DCB_ATTR_IEEE_APP_TABLE: negotiated APP configuration
+ * @DCB_ATTR_IEEE_PEER_ETS: peer ETS configuration - get only
+ * @DCB_ATTR_IEEE_PEER_PFC: peer PFC configuration - get only
+ * @DCB_ATTR_IEEE_PEER_APP: peer APP tlv - get only
+ */
enum ieee_attrs {
DCB_ATTR_IEEE_UNSPEC,
DCB_ATTR_IEEE_ETS,
DCB_ATTR_IEEE_PFC,
DCB_ATTR_IEEE_APP_TABLE,
+ DCB_ATTR_IEEE_PEER_ETS,
+ DCB_ATTR_IEEE_PEER_PFC,
+ DCB_ATTR_IEEE_PEER_APP,
__DCB_ATTR_IEEE_MAX
};
#define DCB_ATTR_IEEE_MAX (__DCB_ATTR_IEEE_MAX - 1)
@@ -251,6 +281,14 @@ enum ieee_attrs_app {
};
#define DCB_ATTR_IEEE_APP_MAX (__DCB_ATTR_IEEE_APP_MAX - 1)
+enum peer_app_attr {
+ DCB_ATTR_PEER_APP_UNSPEC,
+ DCB_ATTR_PEER_APP_INFO,
+ DCB_ATTR_PEER_APP,
+ __DCB_ATTR_PEER_APP_MAX
+};
+#define DCB_ATTR_PEER_APP_MAX (__DCB_ATTR_PEER_APP_MAX - 1)
+
/**
* enum dcbnl_pfc_attrs - DCB Priority Flow Control user priority nested attrs
*
diff --git a/include/net/dcbnl.h b/include/net/dcbnl.h
index a8e7852..739feb4 100644
--- a/include/net/dcbnl.h
+++ b/include/net/dcbnl.h
@@ -43,6 +43,8 @@ struct dcbnl_rtnl_ops {
int (*ieee_setpfc) (struct net_device *, struct ieee_pfc *);
int (*ieee_getapp) (struct net_device *, struct dcb_app *);
int (*ieee_setapp) (struct net_device *, struct dcb_app *);
+ int (*ieee_peer_getets) (struct net_device *, struct ieee_ets *);
+ int (*ieee_peer_getpfc) (struct net_device *, struct ieee_pfc *);
/* CEE std */
u8 (*getstate)(struct net_device *);
@@ -77,6 +79,9 @@ struct dcbnl_rtnl_ops {
u8 (*getdcbx)(struct net_device *);
u8 (*setdcbx)(struct net_device *, u8);
+ /* peer apps */
+ int (*peer_getappinfo)(struct net_device *, struct dcb_peer_app_info *);
+ int (*peer_getapptable)(struct net_device *, struct dcb_app *);
};
diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
index d5074a5..0eb7461 100644
--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -1224,6 +1224,56 @@ err:
return err;
}
+static int dcbnl_build_peer_app(struct net_device *netdev, struct sk_buff* skb,
+ int attrtype)
+{
+ struct dcb_peer_app_info info;
+ struct dcb_app *table = NULL;
+ const struct dcbnl_rtnl_ops *ops = netdev->dcbnl_ops;
+ int err;
+
+ /**
+ * retrieve the peer app configuration form the driver. If the driver
+ * handlers fail exit without doing anything
+ */
+ err = ops->peer_getappinfo(netdev, &info);
+ if (!err && info.app_count) {
+ table = kmalloc(sizeof(struct dcb_app) * info.app_count,
+ GFP_KERNEL);
+ if (!table)
+ return -ENOMEM;
+
+ err = ops->peer_getapptable(netdev, table);
+ }
+
+ if (!err) {
+ u16 i;
+ struct nlattr *app;
+
+ /**
+ * build the message, from here on the only possible failure
+ * is due to the skb size
+ */
+ err = -EMSGSIZE;
+
+ app = nla_nest_start(skb, attrtype);
+ if (!app)
+ goto nla_put_failure;
+
+ NLA_PUT(skb, DCB_ATTR_PEER_APP_INFO, sizeof(info), &info);
+
+ for (i = 0; i < info.app_count; i++)
+ NLA_PUT(skb, DCB_ATTR_PEER_APP, sizeof(struct dcb_app),
+ &table[i]);
+
+ nla_nest_end(skb, app);
+ }
+ err = 0;
+
+nla_put_failure:
+ kfree(table);
+ return err;
+}
/* Handle IEEE 802.1Qaz GET commands. */
static int dcbnl_ieee_get(struct net_device *netdev, struct nlattr **tb,
@@ -1288,6 +1338,27 @@ static int dcbnl_ieee_get(struct net_device *netdev, struct nlattr **tb,
spin_unlock(&dcb_lock);
nla_nest_end(skb, app);
+ /* get peer info if available */
+ if (ops->ieee_peer_getets) {
+ struct ieee_ets ets;
+ err = ops->ieee_peer_getets(netdev, &ets);
+ if (!err)
+ NLA_PUT(skb, DCB_ATTR_IEEE_PEER_ETS, sizeof(ets), &ets);
+ }
+
+ if (ops->ieee_peer_getpfc) {
+ struct ieee_pfc pfc;
+ err = ops->ieee_peer_getpfc(netdev, &pfc);
+ if (!err)
+ NLA_PUT(skb, DCB_ATTR_IEEE_PEER_PFC, sizeof(pfc), &pfc);
+ }
+
+ if (ops->peer_getappinfo && ops->peer_getapptable) {
+ err = dcbnl_build_peer_app(netdev, skb, DCB_ATTR_IEEE_PEER_APP);
+ if (err)
+ goto nla_put_failure;
+ }
+
nla_nest_end(skb, ieee);
nlmsg_end(skb, nlh);
--
1.7.3.5
^ permalink raw reply related
* Re: [PATCH v4] net: add Faraday FTMAC100 10/100 Ethernet driver
From: David Miller @ 2011-02-24 18:43 UTC (permalink / raw)
To: ratbert.chuang
Cc: mirqus, netdev, linux-kernel, bhutchings, eric.dumazet, joe,
dilinger, ratbert
In-Reply-To: <AANLkTikE_OU_qiBUdiDP39js8jQzGqqo1FYW2uHmw3He@mail.gmail.com>
From: Po-Yu Chuang <ratbert.chuang@gmail.com>
Date: Thu, 24 Feb 2011 16:07:48 +0800
> On Thu, Feb 24, 2011 at 3:51 PM, David Miller <davem@davemloft.net> wrote:
>> Just emit garbage bytes into the sub-word alignment padding if the chip
>> wants to word align it's DMA writes.
>
> Not sure what do you mean. The problem is that HW does not accept a
> base address of RX buffer which is not 8 bytes aligned.
I am saying this is what hardware should do if it has such a
restriction.
^ permalink raw reply
* tun.c non formal header protocol?
From: Kfir Lavi @ 2011-02-24 18:37 UTC (permalink / raw)
To: netdev
In-Reply-To: <AANLkTin-PJs07ruhhbC5U0DmqFd-rP8Csorethz_1kes@mail.gmail.com>
Hi,
I would like to use custom protocol over tun/tap device.
I'm grabbing packets, and changing them, to deliver via tap,
to a listener that knows this custom protocol.
The custom protocol is just wrapping the packet with another
small header.
Is it possible to move custom packets via tun.c ?
Is it possible to have a hook, just before the receiver gets
the packet, and then modify the header of the packet, so
it will not disturb tun.c ?
Is there any other options having the power of Linux stack
and netfilter, and using this custom protocol.
I'm grabbing the packets to userspace using nfq, and then with
verdict I'm returning them to the tap device.
Thanks,
Kfir
^ permalink raw reply
* Re: STMMAC driver: NFS Problem on 2.6.37
From: Chuck Lever @ 2011-02-24 18:33 UTC (permalink / raw)
To: Shiraz Hashim
Cc: Brian Downing, Deepak SIKRI, Armando VISCONTI, Trond Myklebust,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux NFS Mailing List, Viresh KUMAR, Peppe CAVALLARO, amitgoel
In-Reply-To: <20110224133627.GO920@DLHLAP0379>
On Feb 24, 2011, at 5:36 AM, Shiraz Hashim wrote:
> On Thu, Feb 10, 2011 at 05:26:16AM +0800, Chuck Lever wrote:
>>
>> On Feb 9, 2011, at 3:58 PM, Brian Downing wrote:
>>
>>> On Wed, Feb 09, 2011 at 03:12:22PM -0500, Chuck Lever wrote:
>>>> Based on your console logs, I see that the working case uses UDP to
>>>> contact the server's mountd, but the failing case uses TCP. You can
>>>> try explicitly specifying "proto=udp" to force the use of UDP, to test
>>>> this theory.
>>>
>>> This does indeed make it work again for me, thanks!
>>>
>>>> Meanwhile, the patch description explicitly states that the default
>>>> mount option settings have changed. Does it make sense to change the
>>>> default behavior of NFSROOT mounts to use UDP again? I don't see
>>>> another way to make this process more reliable across NIC
>>>> initialization. If this is considered a regression, we can make a
>>>> patch for 2.6.38-rc and 2.6.37.
>>>
>>> I only use nfsroot for development, so I don't have a terribly strong
>>> opinion. I would point out though that the default u-boot parameters
>>> for nfsrooting a lot of boards will no longer work at this point, so if
>>> it's not patched to work again without specifying nfs options I think
>>> there should at least be a note in the documentation and possibly a
>>> "maybe try proto=udp?" console message on failure.
>>>
>>> I assume it's not feasable to either wait until the chosen interface's
>>> link is ready before trying to mount nfsroot, or retrying TCP-based
>>> connections a little bit more aggressively/at all?
>>
>> Our goal is to use the same mount logic for both normal user
>> space mounts and for NFSROOT (that was the purpose of the patch
>> series this particular patch comes from). It's
>> exceptionally difficult to add a special case for retrying TCP
>> connections here, as that would change the behavior of user
>> space mounts, which often want to fail quickly, and don't need
>> to worry about NIC initialization.
>>
>> Sounds like the right thing to do is restore the default UDP behavior. I'll cook up a patch.
>
> Is there some patch available for this now.
Yes, it was posted a couple of weeks ago (sorry, I don't have an exact reference). I will ping Trond again about getting this upstream.
> There is one more observation (on 2.6.37), when I pass
> nfsroot=$(ip):$(rootpath),udp , then it works fine.
> If I pass proto=udp then it doesn't work. Is there any difference
> between the two methods ?
It may be that proto=udp has an effect only on the transport used for NFS requests, but not for the MNT request. "udp" means "proto=udp,mountproto=udp."
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 ref0] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Eric Dumazet @ 2011-02-24 17:48 UTC (permalink / raw)
To: Po-Yu Chuang
Cc: netdev, linux-kernel, bhutchings, joe, dilinger, mirqus, davem,
Po-Yu Chuang
In-Reply-To: <1298569179.2814.11.camel@edumazet-laptop>
Le jeudi 24 février 2011 à 18:39 +0100, Eric Dumazet a écrit :
> Le jeudi 24 février 2011 à 17:29 +0800, Po-Yu Chuang a écrit :
> > From: Po-Yu Chuang <ratbert@faraday-tech.com>
> >
>
>
> > +
> > +static bool ftmac100_rx_packet(struct ftmac100 *priv, int *processed)
> > +{
> > + struct net_device *netdev = priv->netdev;
> > + struct ftmac100_rxdes *rxdes;
> > + struct sk_buff *skb;
> > + struct page *page;
> > + dma_addr_t map;
> > + int length;
> > +
> > + rxdes = ftmac100_rx_locate_first_segment(priv);
> > + if (!rxdes)
> > + return false;
> > +
> > + if (unlikely(ftmac100_rx_packet_error(priv, rxdes))) {
> > + ftmac100_rx_drop_packet(priv);
> > + return true;
> > + }
> > +
> > + /*
> > + * It is impossible to get multi-segment packets
> > + * because we always provide big enough receive buffers.
> > + */
> > + if (unlikely(!ftmac100_rxdes_last_segment(rxdes)))
> > + BUG();
> > +
> > + /* start processing */
> > + skb = netdev_alloc_skb_ip_align(netdev, ETH_HLEN);
>
> Oh I see... You should allocate a bigger head (say... 128 bytes)
>
> And copy in it up to 128 bytes of first part... this to avoid upper
> stack to reallocate skb head (because IP/TCP processing need to get
> their headers in skb head)
Take a look at drivers/net/niu.c :
#define RX_SKB_ALLOC_SIZE 128 + NET_IP_ALIGN
static int niu_process_rx_pkt(...)
{
...
skb = netdev_alloc_skb(np->dev, RX_SKB_ALLOC_SIZE);
...
while (1) {
...
niu_rx_skb_append(skb, page, off, append_size);
}
}
^ permalink raw reply
* Re: [PATCH] Network driver for PMC-Sierra MSP71xx TSMAC.
From: Stephen Hemminger @ 2011-02-24 17:45 UTC (permalink / raw)
To: Anoop P.A; +Cc: davem, khilman, cyril, netdev, linux-kernel, linux-mips
In-Reply-To: <1298548660-10546-1-git-send-email-anoop.pa@gmail.com>
On Thu, 24 Feb 2011 17:27:40 +0530
"Anoop P.A" <anoop.pa@gmail.com> wrote:
> +#if PMC_MSP_TSMAC
> +
> +config DESC_ALL_DSPRAM
> + bool "TX/RX Descriptors in DSPRAM"
> + depends on DMA_TO_SPRAM
> + default n
> + help
> + Turning this on puts TX/RX descriptors in DSPRAM. Otherwise they are in
> + DRAM.
> +
> +config TSMAC_LINELOOPBACK_FEATURE
> + bool "lineLoopBack command"
> + default n
> + help
> + Turning this on includes the lineLoopBack command in the driver's proc
> + interface. Echoing 1 into the lineLoopBack results in all rx packets
> + being transmitted out the same port.
> +
> +config TSMAC_TEST_CMDS
> + bool "test commands"
> + default n
> + help
> + Turning this on includes the testing commands in the driver's proc
> + interface. These are used internally by PMC.
> +
Too many config options. Usually no config options is best, or at
most one debug option.
The proc interface for testing should be replaced with debugfs
^ permalink raw reply
* Re: [PATCH ref0] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Eric Dumazet @ 2011-02-24 17:39 UTC (permalink / raw)
To: Po-Yu Chuang
Cc: netdev, linux-kernel, bhutchings, joe, dilinger, mirqus, davem,
Po-Yu Chuang
In-Reply-To: <1298539762-2242-1-git-send-email-ratbert.chuang@gmail.com>
Le jeudi 24 février 2011 à 17:29 +0800, Po-Yu Chuang a écrit :
> From: Po-Yu Chuang <ratbert@faraday-tech.com>
>
> +
> +static bool ftmac100_rx_packet(struct ftmac100 *priv, int *processed)
> +{
> + struct net_device *netdev = priv->netdev;
> + struct ftmac100_rxdes *rxdes;
> + struct sk_buff *skb;
> + struct page *page;
> + dma_addr_t map;
> + int length;
> +
> + rxdes = ftmac100_rx_locate_first_segment(priv);
> + if (!rxdes)
> + return false;
> +
> + if (unlikely(ftmac100_rx_packet_error(priv, rxdes))) {
> + ftmac100_rx_drop_packet(priv);
> + return true;
> + }
> +
> + /*
> + * It is impossible to get multi-segment packets
> + * because we always provide big enough receive buffers.
> + */
> + if (unlikely(!ftmac100_rxdes_last_segment(rxdes)))
> + BUG();
> +
> + /* start processing */
> + skb = netdev_alloc_skb_ip_align(netdev, ETH_HLEN);
Oh I see... You should allocate a bigger head (say... 128 bytes)
And copy in it up to 128 bytes of first part... this to avoid upper
stack to reallocate skb head (because IP/TCP processing need to get
their headers in skb head)
> + if (unlikely(!skb)) {
> + if (net_ratelimit())
> + netdev_err(netdev, "rx skb alloc failed\n");
> +
> + ftmac100_rx_drop_packet(priv);
> + return true;
> + }
> +
> + if (unlikely(ftmac100_rxdes_multicast(rxdes)))
> + netdev->stats.multicast++;
> +
> + map = ftmac100_rxdes_get_dma_addr(rxdes);
> + dma_unmap_page(priv->dev, map, RX_BUF_SIZE, DMA_FROM_DEVICE);
> +
> + length = ftmac100_rxdes_frame_length(rxdes);
> + page = ftmac100_rxdes_get_page(rxdes);
> + skb_fill_page_desc(skb, 0, page, 0, length);
> + skb->len += length;
> + skb->data_len += length;
> + skb->truesize += length;
> + __pskb_pull_tail(skb, ETH_HLEN);
> +
> + ftmac100_alloc_rx_page(priv, rxdes);
> +
> + ftmac100_rx_pointer_advance(priv);
> +
> + skb->protocol = eth_type_trans(skb, netdev);
> +
> + netdev->stats.rx_packets++;
> + netdev->stats.rx_bytes += skb->len;
> +
> + /* push packet to protocol stack */
> + netif_receive_skb(skb);
> +
> + (*processed)++;
> + return true;
> +}
> +
^ permalink raw reply
* Re: [PATCH] Network driver for PMC-Sierra MSP71xx TSMAC.
From: Stephen Hemminger @ 2011-02-24 17:35 UTC (permalink / raw)
To: Anoop P.A; +Cc: davem, khilman, cyril, netdev, linux-kernel, linux-mips
In-Reply-To: <1298548660-10546-1-git-send-email-anoop.pa@gmail.com>
On Thu, 24 Feb 2011 17:27:40 +0530
"Anoop P.A" <anoop.pa@gmail.com> wrote:
> +const char version[] = "pmcmsp_tsmac.c:v2.0 01/09/2007, PMC-Sierra\n";
> +const char cardname[] = "pmcmsp_tsmac";
All data and functions that are only used by this driver should be marked static.
> +const char drv_reldate[] = "$Date: 2010/07/15 07:38:59 $";
> +const char drv_file[] = __FILE__;
This is bogus noise.
--
^ permalink raw reply
* Re: [PATCH V11 2/4] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Scott Wood @ 2011-02-24 17:27 UTC (permalink / raw)
To: Richard Cochran
Cc: Grant Likely, Thomas Gleixner, Rodolfo Giometti, Arnd Bergmann,
Peter Zijlstra, linux-api, devicetree-discuss, linux-kernel,
Russell King, Paul Mackerras, John Stultz, Alan Cox, netdev,
Mike Frysinger, Christoph Lameter, linuxppc-dev, David Miller,
linux-arm-kernel, Krzysztof Halasa
In-Reply-To: <20110224165004.GB15234@riccoc20.at.omicron.at>
On Thu, 24 Feb 2011 17:50:04 +0100
Richard Cochran <richardcochran@gmail.com> wrote:
> On Wed, Feb 23, 2011 at 01:24:44PM -0600, Scott Wood wrote:
> > Whatever string is used should be written into a binding document.
> >
> > fsl,etsec-v1.6-ptp seems like it would be just as good for that purpose.
> >
> > Even just fsl,etsec-ptp will identify the binding, though it's lacking in
> > identifying the hardware (in the absence of access to the eTSEC ID
> > registers).
>
> I read the conversation, and I don't mind admitting that I do not
> understand what you both are arguing/discussing about.
>
> How should I set the strings? Like this?
>
> arch/powerpc/boot/dts/mpc8313erdb.dts:
> ptp_clock@24E00 {
> compatible = "fsl,mpc8313-etsec-ptp";
> }
> arch/powerpc/boot/dts/mpc8572ds.dts:
> ptp_clock@24E00 {
> compatible = "fsl,mpc8572-etsec-ptp";
> }
> arch/powerpc/boot/dts/p2020ds.dts:
> ptp_clock@24E00 {
> compatible = "fsl,p2020ds-etsec-ptp";
> }
> arch/powerpc/boot/dts/p2020rdb.dts:
> ptp_clock@24E00 {
> compatible = "fsl,p2020rdb-etsec-ptp";
> }
>
> drivers/net/gianfar_ptp.c:
>
> static struct of_device_id match_table[] = {
> { .compatible = "fsl,mpc8313-etsec-ptp" },
> { .compatible = "fsl,mpc8572-etsec-ptp" },
> { .compatible = "fsl,p2020ds-etsec-ptp" },
> { .compatible = "fsl,p2020rdb-etsec-ptp" },
> {},
> };
Those last two are boards, not chips. I don't think even Grant is asking
to take things that far.
My vote, if it goes in a separate node at all, is "fsl,etsec-ptp", and let
the driver use SVR. Even encoding an etsec version in the compatible
string would be difficult, unless fixed up by u-boot, as it appears to
differ based on chip revision (and the chip manuals seem to often not match
the hardware regarding the advertised eTSEC revision) and we don't normally
have separate dts files for different revisions of the same chip. Plus,
our docs (at least the public ones) don't seem to be very helpful in
determining what version of eTSEC implies what.
If you want to use chip-based compatibles instead, then use the actual name
of the chip. You'll need to verify 100% compatibility if you want to claim
compatibility with another chip; it's probably easier/safer to just list
every single Freescale chip that has this type of PTP in a huge compatible
table, like PCI drivers do.
-Scott
^ permalink raw reply
* Re: [PATCH V11 2/4] ptp: Added a clock that uses the eTSEC found on the MPC85xx.
From: Richard Cochran @ 2011-02-24 17:26 UTC (permalink / raw)
To: Grant Likely
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, Alan Cox, Arnd Bergmann,
Christoph Lameter, David Miller, John Stultz, Krzysztof Halasa,
Peter Zijlstra, Rodolfo Giometti, Thomas Gleixner,
Benjamin Herrenschmidt, Mike Frysinger, Paul Mackerras,
Russell King
In-Reply-To: <20110223165058.GE14597-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
On Wed, Feb 23, 2011 at 09:50:58AM -0700, Grant Likely wrote:
> On Wed, Feb 23, 2011 at 11:38:17AM +0100, Richard Cochran wrote:
> > +Clock Properties:
> > +
> > + - tclk-period Timer reference clock period in nanoseconds.
> > + - tmr-prsc Prescaler, divides the output clock.
> > + - tmr-add Frequency compensation value.
> > + - cksel 0= external clock, 1= eTSEC system clock, 3= RTC clock input.
> > + Currently the driver only supports choice "1".
>
> I'd be hesitant about defining something that isn't actually
> implemented yet. You may find the binding to be insufficient at a
> later date.
Okay, I'll remove it.
We never got the external VCO working anyhow.
> > + - tmr-fiper1 Fixed interval period pulse generator.
> > + - tmr-fiper2 Fixed interval period pulse generator.
> > + - max-adj Maximum frequency adjustment in parts per billion.
>
> These are all custom properties (not part of any shared binding) so
> they should probably be prefixed with 'fsl,'.
Okay, fine.
> > + The calculation for tmr_fiper2 is the same as for tmr_fiper1. The
> > + driver expects that tmr_fiper1 will be correctly set to produce a 1
> > + Pulse Per Second (PPS) signal, since this will be offered to the PPS
> > + subsystem to synchronize the Linux clock.
>
> Good documentation, thanks. Question though, how many of these values
> will the end user (or board builder) be likely to want to change. It
> is risky encoding the calculation results into the device tree when
> they aren't the actually parameters that will be manipulated, or at
> least very user-unfriendly.
The whole thing is pretty opaque, and my explanation is (IMHO) way
better that Freescale's documentation of how the fipers work.
The board designer / system designer will want to set these carefully,
but never change them. Basically, for a given input clock, there is
only one optimal setting.
I think the device tree is the right place for that kind of setting.
The fiper1 signal should always be a 1 PPS. We could make fiper2 run
time programmable via PHC ioctls, but I think this can wait.
> > + etsects->irq = irq_of_parse_and_map(node, 0);
>
> Use platform_get_irq().
Okay.
> > + etsects->regs = of_iomap(node, 0);
>
> Use platform_get_resource(), and don't forget to request the
> resources.
Okay, but didn't you tell me before to do this way?
http://marc.info/?l=linux-netdev&m=127662247203659&w=4
> > +static struct of_platform_driver gianfar_ptp_driver = {
>
> Use a platform_driver instead. of_platform_driver is deprecated and
> being removed.
Ja, should have noticed that myself, sorry.
> > +++ b/drivers/net/gianfar_ptp_reg.h
>
> This data is only used by gianfar_ptp.c, so there is no need for a
> separate include file. Move the contents of gianfar_ptp_reg.h into
> gianfar_ptp.c
You are right, of course, since private #defines and declarations
should simply stay in their .c files. Some people think that all
#defines and declarations must go into a header file.
I am not one of those people, but in this case, I generated the file
from a little tool I wrote and so kept it separate.
Still, it is no trouble to combine the header into the driver .c file.
Thanks for your review,
Richard
^ permalink raw reply
* Re: [PATCH (sh-2.6) 1/4] clksource: Generic timer infrastructure
From: Arnd Bergmann @ 2011-02-24 17:20 UTC (permalink / raw)
To: Peppe CAVALLARO
Cc: linux-sh@vger.kernel.org, netdev@vger.kernel.org, Stuart MENEFY,
John Stultz, Thomas Gleixner, linux-kernel
In-Reply-To: <1298369864-24429-2-git-send-email-peppe.cavallaro@st.com>
On Tuesday 22 February 2011, Peppe CAVALLARO wrote:
> From: Stuart Menefy <stuart.menefy@st.com>
>
> Many devices targeted at the embedded market provide a number of
> generic timers which are capable of generating interrupts at a
> requested rate. These can then be used in the implementation of drivers
> for other peripherals which require a timer interrupt, without having
> to provide an additional timer as part of that peripheral.
>
> A code provides a simple abstraction layer which allows a timer to be
> registered, and for a driver to request a timer.
>
> Currently this doesn't provide any of the additional information, such
> as precision or position in clock framework which might be required
> for a fully featured driver.
This code should probably be discussed on a more broader
platform than the netdev and linux-sh mailing lists,
as the scope is neither sh nor network specific.
You should at least add linux-kernel@vger.kernel.org, possibly
also linux-arch@vger.kernel.org.
Further, John and Thomas are responsible for the timekeeping
infrastructure, and they are probably interested in this
as well.
Why is this code useful to you? In the scenarios I've seen, the
board can always assign a timer to a specific device in a fixed
way that can be describe in a board file or device tree.
Also, what is the difference between this and clkdev?
> Signed-off-by: Stuart Menefy <stuart.menefy@st.com>
> Hacked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> ---
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/generictimer.c | 60 ++++++++++++++++++++++++++++++++++++
> include/linux/generictimer.h | 41 ++++++++++++++++++++++++
> 3 files changed, 102 insertions(+), 0 deletions(-)
> create mode 100644 drivers/clocksource/generictimer.c
> create mode 100644 include/linux/generictimer.h
I don't think it fits that well into the drivers/clocksource directory,
because you don't actually register a struct clock_event_device or
struct clocksource.
I don't know if this could also be merged with the clocksource infrastructure,
but your code currently doesn't do that.
> +struct generic_timer *generic_timer_claim(void (*handler) (void *), void *data)
> +{
> + struct generic_timer *gt = NULL;
> +
> + if (!handler) {
> + pr_err("%s: invalid handler\n", __func__);
> + return NULL;
> + }
> +
> + mutex_lock(>_mutex);
> + if (!list_empty(>_list)) {
> + struct list_head *list = gt_list.next;
> + list_del(list);
> + gt = container_of(list, struct generic_timer, list);
> + }
> + mutex_unlock(>_mutex);
> +
> + if (!gt)
> + return NULL;
> +
> + /* Prepare the new handler */
> + gt->priv_handler = handler;
> + gt->data = data;
> +
> + return gt;
> +}
This does not seem very generic. You put timers into the list and take
them out again, but don't have any way to deal with timers that match
specific purposes. It obviously works for your specific use case where
you register exactly one timer, and use that in exactly one driver.
If more drivers were converted to generic_timer, which is obviously
the intention, then you might have a situation with very different
timers (fixed/variable tick, high/low frequencies, accurate/inaccurate),
or you might have fewer timers than users.
> +static inline void generic_timer_set_rate(struct generic_timer *gt,
> + unsigned long rate)
> +{
> + gt->set_rate(gt, rate);
> +}
> +
> +#endif /* __STM_GENERIC_TIMER_H */
Shouldn't this one allow a return code?
Arnd
^ 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