* Re: How to compile tcp fast open client app with kernel tfo client support ?
From: Vincent Li @ 2012-11-09 18:47 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: netdev
In-Reply-To: <CAGK4HS-U+Ov5x8z+1CRZdiAD9MhfBUfurKKBbt1EWGYFLN8TcA@mail.gmail.com>
On Fri, Nov 9, 2012 at 10:23 AM, Vijay Subramanian
<subramanian.vijay@gmail.com> wrote:
>> htmlgettfo.c: In function 'get_page_thread':
>> htmlgettfo.c:109: error: 'MSG_FASTOPEN' undeclared (first use in this function)
>> htmlgettfo.c:109: error: (Each undeclared identifier is reported only once
>> htmlgettfo.c:109: error: for each function it appears in.)
>>
>> I have the 3.6.0 kernel header file package installed
>> /usr/src/linux-headers-3.6.0-custom, the user space include file
>> /usr/include/linux is original one coming with 10.0.4 distro kernel
>>
>> I am suspecting I don't have proper linux header file that has
>> MSG_FASTOPEN declared in user space. can anyone shed a light on how to
>> get MSG_FASTOPEN supported and compiled in client code properly?
>>
>
> Vincent ,
> You can try adding the following to the client code.
>
> #define MSG_FASTOPEN 0x20000000
>
> This is missing still from user space header files I presume.
>
> Vijay
Thanks Vijay, that did it. and the load banlancer doesn't recognize
the option, but traffic pass through ok. the data is sent through the
final ack of 3WHS from linux.
Vincent
^ permalink raw reply
* Re: How to compile tcp fast open client app with kernel tfo client support ?
From: Vijay Subramanian @ 2012-11-09 18:23 UTC (permalink / raw)
To: Vincent Li; +Cc: netdev
In-Reply-To: <CAK3+h2xmgy+RhUy=MZ5Cu8Zpz+gQmt3dXCX0tpLAWFCTeujBLA@mail.gmail.com>
> htmlgettfo.c: In function 'get_page_thread':
> htmlgettfo.c:109: error: 'MSG_FASTOPEN' undeclared (first use in this function)
> htmlgettfo.c:109: error: (Each undeclared identifier is reported only once
> htmlgettfo.c:109: error: for each function it appears in.)
>
> I have the 3.6.0 kernel header file package installed
> /usr/src/linux-headers-3.6.0-custom, the user space include file
> /usr/include/linux is original one coming with 10.0.4 distro kernel
>
> I am suspecting I don't have proper linux header file that has
> MSG_FASTOPEN declared in user space. can anyone shed a light on how to
> get MSG_FASTOPEN supported and compiled in client code properly?
>
Vincent ,
You can try adding the following to the client code.
#define MSG_FASTOPEN 0x20000000
This is missing still from user space header files I presume.
Vijay
^ permalink raw reply
* RE: SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
From: Li, Sibai @ 2012-11-09 18:08 UTC (permalink / raw)
To: Rose, Gregory V, Jason Gao; +Cc: Kirsher, Jeffrey T, linux-kernel, netdev, kvm
In-Reply-To: <C5551D9AAB213A418B7FD5E4A6F30A072D5683CF@ORSMSX106.amr.corp.intel.com>
Jason,
DellR710 with the latest BIOS should work fine for SR-IOV. My BIOS is v.6.3.0 and release date is 07/24/2012
Please check if you configured intel_iommu=on in the grub.conf file.
If you did, check your kernel .config file under Device Drivers-> IOMMU Hardware support->enable Support for Intel IOMMU using DMA remapping Devices, enable Intel DMA Remapping Devices by Default, enable Support for Interrupt Remapping.
Thanks,
Sibai
> -----Original Message-----
> From: Rose, Gregory V
> Sent: Friday, November 09, 2012 9:16 AM
> To: Jason Gao; Li, Sibai
> Cc: Kirsher, Jeffrey T; linux-kernel; netdev; kvm
> Subject: RE: SR-IOV problem with Intel 82599EB (not enough MMIO resources
> for SR-IOV)
>
> > -----Original Message-----
> > From: Jason Gao [mailto:pkill.2012@gmail.com]
> > Sent: Thursday, November 08, 2012 8:00 PM
> > To: Rose, Gregory V
> > Cc: Kirsher, Jeffrey T; linux-kernel; netdev; kvm; e1000-
> > devel@lists.sourceforge.net
> > Subject: Re: SR-IOV problem with Intel 82599EB (not enough MMIO
> > resources for SR-IOV)
> >
> > > The BIOS in your machine doesn't support SR-IOV. You'll need to ask
> > > the
> > manufacturer for a BIOS upgrade, if in fact one is available.
> > Sometimes they're not.
> >
> > very thanks Greg,my server Dell R710 with latest BIOS version and
> > option for SR-IOV(SR-IOV Global Enable->Enabled) opened,I'm confused
> > that Does
> > R710 provide full support for SR-IOV, kernel or ixgbe driver's bug?
> > but I'm not sure where the problem lies,anyone has any
> > experience about this? .
>
> I use a Dell R710 for all my SR-IOV testing and it works fine but I had to acquire a
> special BIOS from Dell to get it to work. As I said, you'll want to contact them
> and make sure you've got the correct BIOS.
>
> The error you're seeing, "not enough MMIO resources" has been an issue with
> the BIOS 100% of the times that we've run into it. In any case, it is NOT a driver
> bug. The driver has nothing to do with allocation of MMIO space reservation for
> VF devices. The message you're seeing pops up when the driver calls
> pci_enable_sriov(). There is nothing the driver can do to force that call to be
> successful.
>
> I've added Sibai Li to this response. She should be able to get the BIOS version
> string off of one of our working Dell R710s.
>
> Sibai,
>
> Could you please reply to this message with that information?
>
> Thanks,
>
> - Greg
^ permalink raw reply
* How to compile tcp fast open client app with kernel tfo client support ?
From: Vincent Li @ 2012-11-09 18:05 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]
Hi,
this is sort of off toptic, sorry for the noise.
I am running ubuntu 10.0.4 with kernel 3.6.0 with tfo client support,
then I have simple client code that i want to use to test tcp fast
open, here is part of the code:
int sent = 0;
while(sent < strlen(get))
{
tmpres = sendto(sock, get+sent, strlen(get)-sent, MSG_FASTOPEN,
(struct sockaddr *)remote, sizeof(struct sockaddr));
if(tmpres == -1){
perror("Can't send query");
exit(1);
}
sent += tmpres;
}
when i compile it, as gcc -o htmlgettfo htmlgettfo.c, I got:
htmlgettfo.c: In function 'get_page_thread':
htmlgettfo.c:109: error: 'MSG_FASTOPEN' undeclared (first use in this function)
htmlgettfo.c:109: error: (Each undeclared identifier is reported only once
htmlgettfo.c:109: error: for each function it appears in.)
I have the 3.6.0 kernel header file package installed
/usr/src/linux-headers-3.6.0-custom, the user space include file
/usr/include/linux is original one coming with 10.0.4 distro kernel
I am suspecting I don't have proper linux header file that has
MSG_FASTOPEN declared in user space. can anyone shed a light on how to
get MSG_FASTOPEN supported and compiled in client code properly?
I am attempting to use the test client code to test one of our load
balancer and see how it responds.
I attached my test code
Thanks
Vincent
[-- Attachment #2: htmlgettfo.c.txt --]
[-- Type: text/plain, Size: 4179 bytes --]
#include <stdio.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <stdlib.h>
#include <netdb.h>
#include <string.h>
#include <pthread.h>
#include <unistd.h>
#include <linux-3.6.0/socket.h>
#define MAX_HOST_PAGE 2
struct host_page {
char *host;
char *page;
} hp[MAX_HOST_PAGE];
int tcp_connect(char *host);
char *get_ip(char *host);
char *build_get_query(char *host, char *page);
int *get_page_thread(struct host_page *hp);
void usage();
#define HOST "host.example.com"
#define PAGE "/"
#define PORT 80
#define USERAGENT "HTMLGET 1.0"
int main(int argc, char **argv)
{
struct host_page *hpptr;
if(argc == 1){
usage();
exit(2);
}
hp[0].host = argv[1];
fprintf(stderr, "hp->host:\n%s\n", hp[0].host);
if(argc > 2){
hp[0].page = argv[2];
fprintf(stderr, "host->page:\n%s\n", hp[0].page);
}else{
hp[0].page = PAGE;
}
hpptr = &hp[0];
if(get_page_thread(hpptr)){
perror("Can't get page");
exit(2);
}
}
void usage()
{
fprintf(stderr, "USAGE: htmlget host [page]\n\
\thost: the website hostname. ex: \n\
\tpage: the page to retrieve. ex: index.html, default: /\n");
}
int *get_page_thread(struct host_page *hp){
struct sockaddr_in *remote;
int sock;
int tmpres;
char *ip;
char *host;
char *page;
host=hp->host;
page=hp->page;
char *get;
char buf[BUFSIZ+1];
if((sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0){
perror("Can't create TCP socket");
return 0;
}
ip = get_ip(host);
fprintf(stderr, "IP is %s\n", ip);
remote = (struct sockaddr_in *)malloc(sizeof(struct sockaddr_in *));
remote->sin_family = AF_INET;
tmpres = inet_pton(AF_INET, ip, (void *)(&(remote->sin_addr.s_addr)));
if( tmpres < 0)
{
perror("Can't set remote->sin_addr.s_addr");
return 0;
}else if(tmpres == 0)
{
fprintf(stderr, "%s is not a valid IP address\n", ip);
return 0;
}
remote->sin_port = htons(PORT);
get = build_get_query(host, page);
fprintf(stderr, "Query is:\n<<START>>\n%s<<END>>\n", get);
//Send the query to the server
int sent = 0;
while(sent < strlen(get))
{
tmpres = sendto(sock, get+sent, strlen(get)-sent, MSG_FASTOPEN, (struct sockaddr *)remote, sizeof(struct sockaddr));
if(tmpres == -1){
perror("Can't send query");
exit(1);
}
sent += tmpres;
}
//now it is time to receive the page
memset(buf, 0, sizeof(buf));
int htmlstart = 0;
char * htmlcontent;
while((tmpres = recv(sock, buf, BUFSIZ, 0)) > 0){
if(htmlstart == 0)
{
/* Under certain conditions this will not work.
* If the \r\n\r\n part is splitted into two messages
* it will fail to detect the beginning of HTML content
*/
htmlcontent = strstr(buf, "\r\n\r\n");
if(htmlcontent != NULL){
htmlstart = 1;
htmlcontent += 4;
}
}else{
htmlcontent = buf;
}
if(htmlstart){
/* fprintf(stdout, htmlcontent); */
fprintf(stdout, "%s", htmlcontent);
}
memset(buf, 0, tmpres);
}
if(tmpres < 0)
{
perror("Error receiving data");
}
free(get);
free(remote);
free(ip);
close(sock);
return 0;
}
char *get_ip(char *host)
{
struct hostent *hent;
int iplen = 15; //XXX.XXX.XXX.XXX
char *ip = (char *)malloc(iplen+1);
memset(ip, 0, iplen+1);
if((hent = gethostbyname(host)) == NULL)
{
herror("Can't get IP");
exit(1);
}
if(inet_ntop(AF_INET, (void *)hent->h_addr_list[0], ip, iplen) == NULL)
{
perror("Can't resolve host");
exit(1);
}
return ip;
}
char *build_get_query(char *host, char *page)
{
char *query;
char *getpage = page;
char *tpl = "GET /%s HTTP/1.0\r\nHost: %s\r\nUser-Agent: %s\r\n\r\n";
/*char *tpl = "GET /%s HTTP/1.1\r\nHost: %s\r\nUser-Agent: %s\r\nConnection: close\r\n\r\n"; */
if(getpage[0] == '/'){
getpage = getpage + 1;
fprintf(stderr,"Removing leading \"/\", converting %s to %s\n", page, getpage);
}
// -5 is to consider the %s %s %s in tpl and the ending \0
query = (char *)malloc(strlen(host)+strlen(getpage)+strlen(USERAGENT)+strlen(tpl)-5);
sprintf(query, tpl, getpage, host, USERAGENT);
return query;
}
^ permalink raw reply
* Re: query on dynamic switching between Ethernet ports
From: Rayagond K @ 2012-11-09 18:02 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1352475403.3159.8.camel@bwh-desktop.uk.solarflarecom.com>
yes driver issues soft reset to MAC and PHY.
On Fri, Nov 9, 2012 at 9:06 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Fri, 2012-11-09 at 20:02 +0530, Rayagond K wrote:
>> Hi All,
>>
>> I am implementing handling of dynamic switching between Ethernet ports
>> (1GMbps to 100Mbps mode) using PHY layer, I referred various driver in
>> LXR and doc and I am able to understand the PHY layer and implement in
>> my driver.
>>
>> For now I am able to do following in my driver now,
>>
>> 1. Advertising all the capabilities like FULL duplex, half duplex,
>> pause frames, MII/GMII etc while registering with PHY layer.
>> 2. Able to detect the link up and link down.
>> 3. Able do the auto-negotiation with remote end link partner and
>> program my MAC accordingly.
>> 4. Able to establish the link by connecting and disconnecting the
>> cable many times.
>>
>> But I am facing one problem ie my driver is not able to establish the
>> link when I load the driver first time and connected to 1G port. If I
>> toggle the port connection between MII(10/100Mbps) and GMII(1Gbps) for
>> two/three times and connect it back to GMII ports then driver works
>> fine and it establish the link.
>
> Is the driver resetting everything it needs to when loaded?
>
> Ben.
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
--
wwr
Rayagond
^ permalink raw reply
* RE: SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
From: Rose, Gregory V @ 2012-11-09 17:15 UTC (permalink / raw)
To: Jason Gao, Li, Sibai; +Cc: Kirsher, Jeffrey T, linux-kernel, netdev, kvm
In-Reply-To: <CANmqhJDJXcbUxyt6YD6ktxZCDJ=VqiwhGXP+fLMukQr0o-XwxQ@mail.gmail.com>
> -----Original Message-----
> From: Jason Gao [mailto:pkill.2012@gmail.com]
> Sent: Thursday, November 08, 2012 8:00 PM
> To: Rose, Gregory V
> Cc: Kirsher, Jeffrey T; linux-kernel; netdev; kvm; e1000-
> devel@lists.sourceforge.net
> Subject: Re: SR-IOV problem with Intel 82599EB (not enough MMIO resources
> for SR-IOV)
>
> > The BIOS in your machine doesn't support SR-IOV. You'll need to ask the
> manufacturer for a BIOS upgrade, if in fact one is available. Sometimes
> they're not.
>
> very thanks Greg,my server Dell R710 with latest BIOS version and option
> for SR-IOV(SR-IOV Global Enable->Enabled) opened,I'm confused that Does
> R710 provide full support for SR-IOV, kernel or ixgbe driver's bug? but
> I'm not sure where the problem lies,anyone has any
> experience about this? .
I use a Dell R710 for all my SR-IOV testing and it works fine but I had to acquire a special BIOS from Dell to get it to work. As I said, you'll want to contact them and make sure you've got the correct BIOS.
The error you're seeing, "not enough MMIO resources" has been an issue with the BIOS 100% of the times that we've run into it. In any case, it is NOT a driver bug. The driver has nothing to do with allocation of MMIO space reservation for VF devices. The message you're seeing pops up when the driver calls pci_enable_sriov(). There is nothing the driver can do to force that call to be successful.
I've added Sibai Li to this response. She should be able to get the BIOS version string off of one of our working Dell R710s.
Sibai,
Could you please reply to this message with that information?
Thanks,
- Greg
^ permalink raw reply
* Re: question on netdev_completed_queue()
From: Ben Hutchings @ 2012-11-09 17:09 UTC (permalink / raw)
To: Oliver Neukum; +Cc: netdev
In-Reply-To: <16131769.FsMAT47cqV@linux-lqwf.site>
On Fri, 2012-11-09 at 17:58 +0100, Oliver Neukum wrote:
> On Thursday 08 November 2012 20:44:13 Ben Hutchings wrote:
> > On Thu, 2012-11-08 at 20:38 +0100, Oliver Neukum wrote:
> > > Hi,
> > >
> > > is this function to be called whenever a driver is done with transmitting
> > > data, whether the transmission be successful or not?
> >
> > Yes, BQL tracks number of packets and bytes in each queue and you have
> > to tell it about all insertions and removals from the queue. (Except
> > that if you flush the queue, you can use netdev_reset_queue() rather
> > than trying to counting the remaining packets and bytes.)
>
> Thank you. That opens up the next question. How exact does the count
> have to be? Do you care about the exact amount of data or does it just
> have to be internally consistent?
The underlying DQL algorithm doesn't care what it's counting. However
the administrator can adjust the queue limits through sysfs, and they
will expect the numbers to be byte counts.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next 1/3] ipip: advertise tunnel param via rtnl
From: Nicolas Dichtel @ 2012-11-09 17:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem
In-Reply-To: <1352479020.19779.741.camel@edumazet-glaptop>
Le 09/11/2012 17:37, Eric Dumazet a écrit :
> On Fri, 2012-11-09 at 17:09 +0100, Nicolas Dichtel wrote:
>> It is usefull for daemons that monitor link event to have the full parameters of
>> these interfaces when a rtnl message is sent.
>> It allows also to dump them via rtnetlink.
>>
>> It is based on what is done for GRE tunnels.
>>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> ---
>
> Nice !
>
> Note this also adds support for link creation.
>
> Do you plan to add iproute2 support for :
>
> ip link add ipip1 type ipip remote 10.246.8.36
>
> Thanks
>
> Acked-by: Eric Dumazet <edumazet@google.com>
If the principle is approved, yes. If we add it, we will have two
ways to manage these tunnels, via netlink and via ioctl, is it ok?
A side effect could be to have an option or an argument to the module to not
create the control interface (tunl0, sit0, ...).
^ permalink raw reply
* Re: question on netdev_completed_queue()
From: Oliver Neukum @ 2012-11-09 16:58 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1352407453.2771.18.camel@bwh-desktop.uk.solarflarecom.com>
On Thursday 08 November 2012 20:44:13 Ben Hutchings wrote:
> On Thu, 2012-11-08 at 20:38 +0100, Oliver Neukum wrote:
> > Hi,
> >
> > is this function to be called whenever a driver is done with transmitting
> > data, whether the transmission be successful or not?
>
> Yes, BQL tracks number of packets and bytes in each queue and you have
> to tell it about all insertions and removals from the queue. (Except
> that if you flush the queue, you can use netdev_reset_queue() rather
> than trying to counting the remaining packets and bytes.)
Thank you. That opens up the next question. How exact does the count
have to be? Do you care about the exact amount of data or does it just
have to be internally consistent?
Regards
Oliver
^ permalink raw reply
* Re: SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
From: Yinghai Lu @ 2012-11-09 16:56 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: kvm, e1000-devel@lists.sourceforge.net, netdev, linux-kernel,
linux-pci
In-Reply-To: <CAErSpo4xn9t=4yXGLdPQMtUJF=n38tYrMutAoj7NCsLUzQEbcg@mail.gmail.com>
On Fri, Nov 9, 2012 at 7:26 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> [+ linux-pci, Yinghai]
>
> On Thu, Nov 8, 2012 at 8:59 PM, Jason Gao <pkill.2012@gmail.com> wrote:
>>> The BIOS in your machine doesn't support SR-IOV. You'll need to ask the manufacturer for a BIOS upgrade, if in fact one is available. Sometimes they're not.
>>
>> very thanks Greg,my server Dell R710 with latest BIOS version and
>> option for SR-IOV(SR-IOV Global Enable->Enabled) opened,I'm confused
>> that Does R710 provide full support for SR-IOV, kernel or ixgbe
>> driver's bug? but I'm not sure where the problem lies,anyone has any
>> experience about this? .
>
> Linux normally uses the resource assignments done by the BIOS, but it
> is possible for the kernel to reassign those. We don't have good
> automatic support for that yet, but on a recent upstream kernel, you
> can try "pci=realloc". I doubt this option is in CentOS 6.3, though.
>
> If an upstream kernel with "pci=realloc" still doesn't work, please
> post the entire dmesg log.
Even better, upstream kernel will enable realloc automatically if it
finds some SRIOV BAR is not assigned.
related logic is in pci_realloc_detect().
BTW, we may need another patch about realloc.
http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=patch;h=afb9975bddd92b17c2f9859676ce521e2e014997
>From afb9975bddd92b17c2f9859676ce521e2e014997 Mon Sep 17 00:00:00 2001
From: Yinghai Lu <yinghai@kernel.org>
Date: Wed, 3 Oct 2012 19:15:57 -0700
Subject: [PATCH] PCI: Add root bus children dev's res to fail list
We can stop trying according to try number now and do not need to use
root_bus checking as stop sign anymore.
In extreme case we could need to reallocate resource for device just
under root bus.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
drivers/pci/setup-bus.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 1e808ca..9e625d84 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -283,7 +283,7 @@ static void
assign_requested_resources_sorted(struct list_head *head,
idx = res - &dev_res->dev->resource[0];
if (resource_size(res) &&
pci_assign_resource(dev_res->dev, idx)) {
- if (fail_head && !pci_is_root_bus(dev_res->dev->bus)) {
+ if (fail_head) {
/*
* if the failed res is for ROM BAR, and it will
* be enabled later, don't add it to the list
--
1.7.7.6
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: [PATCH net-next 1/3] ipip: advertise tunnel param via rtnl
From: Eric Dumazet @ 2012-11-09 16:37 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem
In-Reply-To: <1352477401-19044-2-git-send-email-nicolas.dichtel@6wind.com>
On Fri, 2012-11-09 at 17:09 +0100, Nicolas Dichtel wrote:
> It is usefull for daemons that monitor link event to have the full parameters of
> these interfaces when a rtnl message is sent.
> It allows also to dump them via rtnetlink.
>
> It is based on what is done for GRE tunnels.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
Nice !
Note this also adds support for link creation.
Do you plan to add iproute2 support for :
ip link add ipip1 type ipip remote 10.246.8.36
Thanks
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH] gre6: fix rtnl dump messages
From: Eric Dumazet @ 2012-11-09 16:09 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem
In-Reply-To: <1352475296-14675-1-git-send-email-nicolas.dichtel@6wind.com>
On Fri, 2012-11-09 at 16:34 +0100, Nicolas Dichtel wrote:
> Spotted after a code review.
> Introduced by c12b395a46646bab69089ce7016ac78177f6001f (gre: Support GRE over
> IPv6).
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> v2: rebase the patch against net
> add the commit that introduces the bug
Thanks !
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH] gianfar: ethernet vanishes after restoring from hibernation
From: Claudiu Manoil @ 2012-11-09 16:02 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: netdev, Wang Dongsheng
In-Reply-To: <1352472231-17927-1-git-send-email-paul.gortmaker@windriver.com>
On 11/9/2012 4:43 PM, Paul Gortmaker wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> If a gianfar ethernet device is down prior to hibernating a
> system, it will no longer be present upon system restore.
>
> For example:
>
> ~# ifconfig eth0 down
> ~# echo disk > /sys/power/state
>
> <trigger a restore from hibernation>
>
> ~# ifconfig eth0 up
> SIOCSIFFLAGS: No such device
>
> This happens because the restore function bails out early upon
> finding devices that were not up at hibernation. In doing so,
> it never gets to the netif_device_attach call at the end of
> the restore function. Adding the netif_device_attach as done
> here also makes the gfar_restore code consistent with what is
> done in the gfar_resume code.
>
> Cc: Claudiu Manoil <claudiu.manoil@freescale.com>
Hello Paul,
Thought I don't have the proper setup to test the hibernation feature,
I agree with this patch especially now that the description is much
clearer. I fully agree on the consistency argument b/w gfar_restore and
gfar_resume. (good observation)
Acked-by: Claudiu Manoil <claudiu.manoil@freescale.com>
^ permalink raw reply
* [PATCH] iproute2: avoid errors from double-installing manpages
From: Andreas Henriksson @ 2012-11-09 15:42 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Three manpages in man8 are listed twice in MAN8PAGES (both directly and
in TARGETS) which causes the install command to spit our a couple of
warnings as below and exiting with non-zero exit code....
make[3]: Entering directory `/tmp/buildd/iproute-20121001/man/man8'
install -m 0755 -d /tmp/buildd/iproute-20121001/debian/tmp/usr/share/man/man8
install -m 0644 ip-address.8 ip-link.8 ip-route.8 ip.8 arpd.8 lnstat.8 routel.8 rtacct.8 rtmon.8 ss.8 tc.8 tc-bfifo.8 tc-cbq.8 tc-cbq-details.8 tc-choke.8 tc-codel.8 tc-drr.8 tc-ematch.8 tc-fq_codel.8 tc-hfsc.8 tc-htb.8 tc-netem.8 tc-pfifo.8 tc-pfifo_fast.8 tc-prio.8 tc-red.8 tc-sfb.8 tc-sfq.8 tc-stab.8 tc-tbf.8 bridge.8 rtstat.8 ctstat.8 nstat.8 routef.8 ip-address.8 ip-addrlabel.8 ip-l2tp.8 ip-link.8 ip-maddress.8 ip-monitor.8 ip-mroute.8 ip-neighbour.8 ip-netns.8 ip-ntable.8 ip-route.8 ip-rule.8 ip-tunnel.8 ip-xfrm.8 /tmp/buildd/iproute-20121001/debian/tmp/usr/share/man/man8
install: will not overwrite just-created `/tmp/buildd/iproute-20121001/debian/tmp/usr/share/man/man8/ip-address.8' with `ip-address.8'
install: will not overwrite just-created `/tmp/buildd/iproute-20121001/debian/tmp/usr/share/man/man8/ip-link.8' with `ip-link.8'
install: will not overwrite just-created `/tmp/buildd/iproute-20121001/debian/tmp/usr/share/man/man8/ip-route.8' with `ip-route.8'
make[3]: *** [install] Error 1
make[3]: Leaving directory `/tmp/buildd/iproute-20121001/man/man8'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/tmp/buildd/iproute-20121001/man'
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
diff --git a/man/man8/Makefile b/man/man8/Makefile
index aaf1729..4bad9d6 100644
--- a/man/man8/Makefile
+++ b/man/man8/Makefile
@@ -1,19 +1,19 @@
TARGETS = ip-address.8 ip-link.8 ip-route.8
MAN8PAGES = $(TARGETS) ip.8 arpd.8 lnstat.8 routel.8 rtacct.8 rtmon.8 ss.8 \
tc.8 tc-bfifo.8 tc-cbq.8 tc-cbq-details.8 tc-choke.8 tc-codel.8 \
tc-drr.8 tc-ematch.8 tc-fq_codel.8 tc-hfsc.8 tc-htb.8 \
tc-netem.8 tc-pfifo.8 tc-pfifo_fast.8 tc-prio.8 tc-red.8 \
tc-sfb.8 tc-sfq.8 tc-stab.8 tc-tbf.8 \
bridge.8 rtstat.8 ctstat.8 nstat.8 routef.8 \
- ip-address.8 ip-addrlabel.8 ip-l2tp.8 ip-link.8 \
+ ip-addrlabel.8 ip-l2tp.8 \
ip-maddress.8 ip-monitor.8 ip-mroute.8 ip-neighbour.8 \
- ip-netns.8 ip-ntable.8 ip-route.8 ip-rule.8 ip-tunnel.8 ip-xfrm.8 \
+ ip-netns.8 ip-ntable.8 ip-rule.8 ip-tunnel.8 ip-xfrm.8 \
ip-tcp_metrics.8
all: $(TARGETS)
ip-address.8: ip-address.8.in
sed "s|@SYSCONFDIR@|$(CONFDIR)|g" $< > $@
ip-link.8: ip-link.8.in
^ permalink raw reply related
* [PATCH net-next 2/3] sit: advertise tunnel param via rtnl
From: Nicolas Dichtel @ 2012-11-09 16:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, davem, Nicolas Dichtel
In-Reply-To: <1352477401-19044-1-git-send-email-nicolas.dichtel@6wind.com>
It is usefull for daemons that monitor link event to have the full parameters of
these interfaces when a rtnl message is sent.
It allows also to dump them via rtnetlink.
It is based on what is done for GRE tunnels.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/sit.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 3ed54ff..b543c56 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -68,6 +68,7 @@
static int ipip6_tunnel_init(struct net_device *dev);
static void ipip6_tunnel_setup(struct net_device *dev);
static void ipip6_dev_free(struct net_device *dev);
+static struct rtnl_link_ops sit_link_ops __read_mostly;
static int sit_net_id __read_mostly;
struct sit_net {
@@ -282,6 +283,7 @@ static struct ip_tunnel *ipip6_tunnel_locate(struct net *net,
goto failed_free;
strcpy(nt->parms.name, dev->name);
+ dev->rtnl_link_ops = &sit_link_ops;
dev_hold(dev);
@@ -1216,6 +1218,47 @@ static int __net_init ipip6_fb_tunnel_init(struct net_device *dev)
return 0;
}
+static size_t sit_get_size(const struct net_device *dev)
+{
+ return
+ /* IFLA_IPTUN_LINK */
+ nla_total_size(4) +
+ /* IFLA_IPTUN_LOCAL */
+ nla_total_size(4) +
+ /* IFLA_IPTUN_REMOTE */
+ nla_total_size(4) +
+ /* IFLA_IPTUN_TTL */
+ nla_total_size(1) +
+ /* IFLA_IPTUN_TOS */
+ nla_total_size(1) +
+ 0;
+}
+
+static int sit_fill_info(struct sk_buff *skb, const struct net_device *dev)
+{
+ struct ip_tunnel *tunnel = netdev_priv(dev);
+ struct ip_tunnel_parm *parm = &tunnel->parms;
+
+ if (nla_put_u32(skb, IFLA_IPTUN_LINK, parm->link) ||
+ nla_put_be32(skb, IFLA_IPTUN_LOCAL, parm->iph.saddr) ||
+ nla_put_be32(skb, IFLA_IPTUN_REMOTE, parm->iph.daddr) ||
+ nla_put_u8(skb, IFLA_IPTUN_TTL, parm->iph.ttl) ||
+ nla_put_u8(skb, IFLA_IPTUN_TOS, parm->iph.tos))
+ goto nla_put_failure;
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+
+static struct rtnl_link_ops sit_link_ops __read_mostly = {
+ .kind = "sit",
+ .maxtype = IFLA_IPTUN_MAX,
+ .priv_size = sizeof(struct ip_tunnel),
+ .get_size = sit_get_size,
+ .fill_info = sit_fill_info,
+};
+
static struct xfrm_tunnel sit_handler __read_mostly = {
.handler = ipip6_rcv,
.err_handler = ipip6_err,
@@ -1302,6 +1345,7 @@ static struct pernet_operations sit_net_ops = {
static void __exit sit_cleanup(void)
{
+ rtnl_link_unregister(&sit_link_ops);
xfrm4_tunnel_deregister(&sit_handler, AF_INET6);
unregister_pernet_device(&sit_net_ops);
@@ -1319,10 +1363,21 @@ static int __init sit_init(void)
return err;
err = xfrm4_tunnel_register(&sit_handler, AF_INET6);
if (err < 0) {
- unregister_pernet_device(&sit_net_ops);
pr_info("%s: can't add protocol\n", __func__);
+ goto xfrm_tunnel_failed;
}
+ err = rtnl_link_register(&sit_link_ops);
+ if (err < 0)
+ goto rtnl_link_failed;
+
+out:
return err;
+
+rtnl_link_failed:
+ xfrm4_tunnel_deregister(&sit_handler, AF_INET6);
+xfrm_tunnel_failed:
+ unregister_pernet_device(&sit_net_ops);
+ goto out;
}
module_init(sit_init);
--
1.7.12
^ permalink raw reply related
* [PATCH net-next 1/3] ipip: advertise tunnel param via rtnl
From: Nicolas Dichtel @ 2012-11-09 16:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, davem, Nicolas Dichtel
In-Reply-To: <1352477401-19044-1-git-send-email-nicolas.dichtel@6wind.com>
It is usefull for daemons that monitor link event to have the full parameters of
these interfaces when a rtnl message is sent.
It allows also to dump them via rtnetlink.
It is based on what is done for GRE tunnels.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/uapi/linux/if_tunnel.h | 11 ++++++++
net/ipv4/ipip.c | 57 +++++++++++++++++++++++++++++++++++++++++-
2 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/if_tunnel.h b/include/uapi/linux/if_tunnel.h
index 5db5942..ccb21d5 100644
--- a/include/uapi/linux/if_tunnel.h
+++ b/include/uapi/linux/if_tunnel.h
@@ -37,6 +37,17 @@ struct ip_tunnel_parm {
struct iphdr iph;
};
+enum {
+ IFLA_IPTUN_UNSPEC,
+ IFLA_IPTUN_LINK,
+ IFLA_IPTUN_LOCAL,
+ IFLA_IPTUN_REMOTE,
+ IFLA_IPTUN_TTL,
+ IFLA_IPTUN_TOS,
+ __IFLA_IPTUN_MAX,
+};
+#define IFLA_IPTUN_MAX (__IFLA_IPTUN_MAX - 1)
+
/* SIT-mode i_flags */
#define SIT_ISATAP 0x0001
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index e15b452..37e1ca2 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -138,6 +138,7 @@ struct ipip_net {
static int ipip_tunnel_init(struct net_device *dev);
static void ipip_tunnel_setup(struct net_device *dev);
static void ipip_dev_free(struct net_device *dev);
+static struct rtnl_link_ops ipip_link_ops __read_mostly;
/*
* Locking : hash tables are protected by RCU and RTNL
@@ -305,6 +306,7 @@ static struct ip_tunnel *ipip_tunnel_locate(struct net *net,
goto failed_free;
strcpy(nt->parms.name, dev->name);
+ dev->rtnl_link_ops = &ipip_link_ops;
dev_hold(dev);
ipip_tunnel_link(ipn, nt);
@@ -829,6 +831,47 @@ static int __net_init ipip_fb_tunnel_init(struct net_device *dev)
return 0;
}
+static size_t ipip_get_size(const struct net_device *dev)
+{
+ return
+ /* IFLA_IPTUN_LINK */
+ nla_total_size(4) +
+ /* IFLA_IPTUN_LOCAL */
+ nla_total_size(4) +
+ /* IFLA_IPTUN_REMOTE */
+ nla_total_size(4) +
+ /* IFLA_IPTUN_TTL */
+ nla_total_size(1) +
+ /* IFLA_IPTUN_TOS */
+ nla_total_size(1) +
+ 0;
+}
+
+static int ipip_fill_info(struct sk_buff *skb, const struct net_device *dev)
+{
+ struct ip_tunnel *tunnel = netdev_priv(dev);
+ struct ip_tunnel_parm *parm = &tunnel->parms;
+
+ if (nla_put_u32(skb, IFLA_IPTUN_LINK, parm->link) ||
+ nla_put_be32(skb, IFLA_IPTUN_LOCAL, parm->iph.saddr) ||
+ nla_put_be32(skb, IFLA_IPTUN_REMOTE, parm->iph.daddr) ||
+ nla_put_u8(skb, IFLA_IPTUN_TTL, parm->iph.ttl) ||
+ nla_put_u8(skb, IFLA_IPTUN_TOS, parm->iph.tos))
+ goto nla_put_failure;
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+
+static struct rtnl_link_ops ipip_link_ops __read_mostly = {
+ .kind = "ipip",
+ .maxtype = IFLA_IPTUN_MAX,
+ .priv_size = sizeof(struct ip_tunnel),
+ .get_size = ipip_get_size,
+ .fill_info = ipip_fill_info,
+};
+
static struct xfrm_tunnel ipip_handler __read_mostly = {
.handler = ipip_rcv,
.err_handler = ipip_err,
@@ -925,14 +968,26 @@ static int __init ipip_init(void)
return err;
err = xfrm4_tunnel_register(&ipip_handler, AF_INET);
if (err < 0) {
- unregister_pernet_device(&ipip_net_ops);
pr_info("%s: can't register tunnel\n", __func__);
+ goto xfrm_tunnel_failed;
}
+ err = rtnl_link_register(&ipip_link_ops);
+ if (err < 0)
+ goto rtnl_link_failed;
+
+out:
return err;
+
+rtnl_link_failed:
+ xfrm4_tunnel_deregister(&ipip_handler, AF_INET);
+xfrm_tunnel_failed:
+ unregister_pernet_device(&ipip_net_ops);
+ goto out;
}
static void __exit ipip_fini(void)
{
+ rtnl_link_unregister(&ipip_link_ops);
if (xfrm4_tunnel_deregister(&ipip_handler, AF_INET))
pr_info("%s: can't deregister tunnel\n", __func__);
--
1.7.12
^ permalink raw reply related
* [PATCH net-next 3/3] ip6tnl: advertise tunnel param via rtnl
From: Nicolas Dichtel @ 2012-11-09 16:10 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, davem, Nicolas Dichtel
In-Reply-To: <1352477401-19044-1-git-send-email-nicolas.dichtel@6wind.com>
It is usefull for daemons that monitor link event to have the full parameters of
these interfaces when a rtnl message is sent.
It allows also to dump them via rtnetlink.
It is based on what is done for GRE tunnels.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/uapi/linux/if_tunnel.h | 3 +++
net/ipv6/ip6_tunnel.c | 57 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 60 insertions(+)
diff --git a/include/uapi/linux/if_tunnel.h b/include/uapi/linux/if_tunnel.h
index ccb21d5..c1bf0b5 100644
--- a/include/uapi/linux/if_tunnel.h
+++ b/include/uapi/linux/if_tunnel.h
@@ -44,6 +44,9 @@ enum {
IFLA_IPTUN_REMOTE,
IFLA_IPTUN_TTL,
IFLA_IPTUN_TOS,
+ IFLA_IPTUN_ENCAP_LIMIT,
+ IFLA_IPTUN_FLOWINFO,
+ IFLA_IPTUN_FLAGS,
__IFLA_IPTUN_MAX,
};
#define IFLA_IPTUN_MAX (__IFLA_IPTUN_MAX - 1)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 09482f7..424ed45 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -83,6 +83,7 @@ static u32 HASH(const struct in6_addr *addr1, const struct in6_addr *addr2)
static int ip6_tnl_dev_init(struct net_device *dev);
static void ip6_tnl_dev_setup(struct net_device *dev);
+static struct rtnl_link_ops ip6_link_ops __read_mostly;
static int ip6_tnl_net_id __read_mostly;
struct ip6_tnl_net {
@@ -299,6 +300,7 @@ static struct ip6_tnl *ip6_tnl_create(struct net *net, struct __ip6_tnl_parm *p)
goto failed_free;
strcpy(t->parms.name, dev->name);
+ dev->rtnl_link_ops = &ip6_link_ops;
dev_hold(dev);
ip6_tnl_link(ip6n, t);
@@ -1504,6 +1506,55 @@ static int __net_init ip6_fb_tnl_dev_init(struct net_device *dev)
return 0;
}
+static size_t ip6_get_size(const struct net_device *dev)
+{
+ return
+ /* IFLA_IPTUN_LINK */
+ nla_total_size(4) +
+ /* IFLA_IPTUN_LOCAL */
+ nla_total_size(sizeof(struct in6_addr)) +
+ /* IFLA_IPTUN_REMOTE */
+ nla_total_size(sizeof(struct in6_addr)) +
+ /* IFLA_IPTUN_TTL */
+ nla_total_size(1) +
+ /* IFLA_IPTUN_ENCAP_LIMIT */
+ nla_total_size(1) +
+ /* IFLA_IPTUN_FLOWINFO */
+ nla_total_size(4) +
+ /* IFLA_IPTUN_FLAGS */
+ nla_total_size(4) +
+ 0;
+}
+
+static int ip6_fill_info(struct sk_buff *skb, const struct net_device *dev)
+{
+ struct ip6_tnl *tunnel = netdev_priv(dev);
+ struct __ip6_tnl_parm *parm = &tunnel->parms;
+
+ if (nla_put_u32(skb, IFLA_IPTUN_LINK, parm->link) ||
+ nla_put(skb, IFLA_IPTUN_LOCAL, sizeof(struct in6_addr),
+ &parm->raddr) ||
+ nla_put(skb, IFLA_IPTUN_REMOTE, sizeof(struct in6_addr),
+ &parm->laddr) ||
+ nla_put_u8(skb, IFLA_IPTUN_TTL, parm->hop_limit) ||
+ nla_put_u8(skb, IFLA_IPTUN_ENCAP_LIMIT, parm->encap_limit) ||
+ nla_put_be32(skb, IFLA_IPTUN_FLOWINFO, parm->flowinfo) ||
+ nla_put_u32(skb, IFLA_IPTUN_FLAGS, parm->flags))
+ goto nla_put_failure;
+ return 0;
+
+nla_put_failure:
+ return -EMSGSIZE;
+}
+
+static struct rtnl_link_ops ip6_link_ops __read_mostly = {
+ .kind = "ip6tnl",
+ .maxtype = IFLA_IPTUN_MAX,
+ .priv_size = sizeof(struct ip6_tnl),
+ .get_size = ip6_get_size,
+ .fill_info = ip6_fill_info,
+};
+
static struct xfrm6_tunnel ip4ip6_handler __read_mostly = {
.handler = ip4ip6_rcv,
.err_handler = ip4ip6_err,
@@ -1612,9 +1663,14 @@ static int __init ip6_tunnel_init(void)
pr_err("%s: can't register ip6ip6\n", __func__);
goto out_ip6ip6;
}
+ err = rtnl_link_register(&ip6_link_ops);
+ if (err < 0)
+ goto rtnl_link_failed;
return 0;
+rtnl_link_failed:
+ xfrm6_tunnel_deregister(&ip6ip6_handler, AF_INET6);
out_ip6ip6:
xfrm6_tunnel_deregister(&ip4ip6_handler, AF_INET);
out_ip4ip6:
@@ -1629,6 +1685,7 @@ out_pernet:
static void __exit ip6_tunnel_cleanup(void)
{
+ rtnl_link_unregister(&ip6_link_ops);
if (xfrm6_tunnel_deregister(&ip4ip6_handler, AF_INET))
pr_info("%s: can't deregister ip4ip6\n", __func__);
--
1.7.12
^ permalink raw reply related
* [PATCH net-next 0/3] Advertise tunnel parameters via netlink
From: Nicolas Dichtel @ 2012-11-09 16:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, davem
In-Reply-To: <1352467239.19779.564.camel@edumazet-glaptop>
The goal of this serie is to advertise tunnel parameters via netlink.
It is usefull for daemons that monitor link event to have the full parameters
of these interfaces.
The patch against iproute2 will be sent once the patches are included and
net-next merged. I can send it on demand.
v2: remove last patch of the serie, which was a bug fix.
enhance commit log.
Comments are welcome.
Regards,
Nicolas
^ permalink raw reply
* Re: query on dynamic switching between Ethernet ports
From: Ben Hutchings @ 2012-11-09 15:36 UTC (permalink / raw)
To: Rayagond K; +Cc: netdev
In-Reply-To: <CAJ3bTp7zXVB5NSj+8J8bR+pvg7mgJ7UjxqhubGxEYmdbpfEVxw@mail.gmail.com>
On Fri, 2012-11-09 at 20:02 +0530, Rayagond K wrote:
> Hi All,
>
> I am implementing handling of dynamic switching between Ethernet ports
> (1GMbps to 100Mbps mode) using PHY layer, I referred various driver in
> LXR and doc and I am able to understand the PHY layer and implement in
> my driver.
>
> For now I am able to do following in my driver now,
>
> 1. Advertising all the capabilities like FULL duplex, half duplex,
> pause frames, MII/GMII etc while registering with PHY layer.
> 2. Able to detect the link up and link down.
> 3. Able do the auto-negotiation with remote end link partner and
> program my MAC accordingly.
> 4. Able to establish the link by connecting and disconnecting the
> cable many times.
>
> But I am facing one problem ie my driver is not able to establish the
> link when I load the driver first time and connected to 1G port. If I
> toggle the port connection between MII(10/100Mbps) and GMII(1Gbps) for
> two/three times and connect it back to GMII ports then driver works
> fine and it establish the link.
Is the driver resetting everything it needs to when loaded?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Optics (SFP) monitoring on ixgbe and igbe
From: Aurélien @ 2012-11-09 15:31 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1352473713.3159.4.camel@bwh-desktop.uk.solarflarecom.com>
On Fri, Nov 9, 2012 at 4:08 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:
>
> No, the driver also needs to implement ethtool_ops::get_module_info and
> ethtool_ops::get_module_eeprom. But those should be quite easy to do.
>
Indeed. But like you said, it should be easy. I shall receive my cards
on monday, i'll try to do the implementation next week.
Best regards,
--
Aurélien Guillaume
- By all means break the rules, and break them beautifully,
deliberately and well. That is one of the ends for which they exist.
-- Robert Bringhurst
^ permalink raw reply
* Re: SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
From: Bjorn Helgaas @ 2012-11-09 15:26 UTC (permalink / raw)
To: Jason Gao
Cc: Rose, Gregory V, Kirsher, Jeffrey T, linux-kernel, netdev, kvm,
e1000-devel@lists.sourceforge.net, linux-pci, Yinghai Lu
In-Reply-To: <CANmqhJDJXcbUxyt6YD6ktxZCDJ=VqiwhGXP+fLMukQr0o-XwxQ@mail.gmail.com>
[+ linux-pci, Yinghai]
On Thu, Nov 8, 2012 at 8:59 PM, Jason Gao <pkill.2012@gmail.com> wrote:
>> The BIOS in your machine doesn't support SR-IOV. You'll need to ask the manufacturer for a BIOS upgrade, if in fact one is available. Sometimes they're not.
>
> very thanks Greg,my server Dell R710 with latest BIOS version and
> option for SR-IOV(SR-IOV Global Enable->Enabled) opened,I'm confused
> that Does R710 provide full support for SR-IOV, kernel or ixgbe
> driver's bug? but I'm not sure where the problem lies,anyone has any
> experience about this? .
Linux normally uses the resource assignments done by the BIOS, but it
is possible for the kernel to reassign those. We don't have good
automatic support for that yet, but on a recent upstream kernel, you
can try "pci=realloc". I doubt this option is in CentOS 6.3, though.
If an upstream kernel with "pci=realloc" still doesn't work, please
post the entire dmesg log.
^ permalink raw reply
* [PATCH] gre6: fix rtnl dump messages
From: Nicolas Dichtel @ 2012-11-09 15:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, davem, Nicolas Dichtel
In-Reply-To: <1352467361.19779.569.camel@edumazet-glaptop>
Spotted after a code review.
Introduced by c12b395a46646bab69089ce7016ac78177f6001f (gre: Support GRE over
IPv6).
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
v2: rebase the patch against net
add the commit that introduces the bug
net/ipv6/ip6_gre.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 0185679..d5cb3c4 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -1633,9 +1633,9 @@ static size_t ip6gre_get_size(const struct net_device *dev)
/* IFLA_GRE_OKEY */
nla_total_size(4) +
/* IFLA_GRE_LOCAL */
- nla_total_size(4) +
+ nla_total_size(sizeof(struct in6_addr)) +
/* IFLA_GRE_REMOTE */
- nla_total_size(4) +
+ nla_total_size(sizeof(struct in6_addr)) +
/* IFLA_GRE_TTL */
nla_total_size(1) +
/* IFLA_GRE_TOS */
@@ -1659,8 +1659,8 @@ static int ip6gre_fill_info(struct sk_buff *skb, const struct net_device *dev)
nla_put_be16(skb, IFLA_GRE_OFLAGS, p->o_flags) ||
nla_put_be32(skb, IFLA_GRE_IKEY, p->i_key) ||
nla_put_be32(skb, IFLA_GRE_OKEY, p->o_key) ||
- nla_put(skb, IFLA_GRE_LOCAL, sizeof(struct in6_addr), &p->raddr) ||
- nla_put(skb, IFLA_GRE_REMOTE, sizeof(struct in6_addr), &p->laddr) ||
+ nla_put(skb, IFLA_GRE_LOCAL, sizeof(struct in6_addr), &p->laddr) ||
+ nla_put(skb, IFLA_GRE_REMOTE, sizeof(struct in6_addr), &p->raddr) ||
nla_put_u8(skb, IFLA_GRE_TTL, p->hop_limit) ||
/*nla_put_u8(skb, IFLA_GRE_TOS, t->priority) ||*/
nla_put_u8(skb, IFLA_GRE_ENCAP_LIMIT, p->encap_limit) ||
--
1.7.12
^ permalink raw reply related
* Re: Optics (SFP) monitoring on ixgbe and igbe
From: Ben Hutchings @ 2012-11-09 15:08 UTC (permalink / raw)
To: footplus; +Cc: netdev
In-Reply-To: <CAPN4dA95RQ+xyvY+qo0CDc=KmaKhuqHATx_KyMjppvauYtUyzQ@mail.gmail.com>
On Thu, 2012-11-08 at 01:39 +0100, Aurélien wrote:
> On Wed, Nov 7, 2012 at 8:58 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:
> > On Wed, 2012-11-07 at 13:27 +0100, Aurélien wrote:
> >
> > We just added the ETHTOOL_GMODULEINFO and ETHTOOL_GMODULEEEPROM
> > interface for this purpose. The diagnostics obviously aren't really an
> > EEPROM but I don't think that matters.
> >
> > These drivers should report a type of ETH_MODULE_SFF_8472 (assuming a
> > module is present) and expose an 'EEPROM' with the real EEPROM in the
> > first 256 bytes and the diagnostic registers in the next 256 bytes.
> >
> > Decoding of the diagnostic registers can be done in ethtool itself.
> >
>
> Hi Ben,
>
> Thanks for this reply.
>
> I did not see these interfaces in my searches, but from what I gather
> from the code, the missing part is the actual decoding of the data in
> ethtool.
[...]
No, the driver also needs to implement ethtool_ops::get_module_info and
ethtool_ops::get_module_eeprom. But those should be quite easy to do.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Lower wake up time when phy enter lower mode
From: Ben Hutchings @ 2012-11-09 15:07 UTC (permalink / raw)
To: Frank Li; +Cc: Richard Cochran, netdev
In-Reply-To: <CAHrpEqQYXxADPrYd=TwqEPaecWt_yjgkivCR6iek9qk0z73WzQ@mail.gmail.com>
On Thu, 2012-11-08 at 10:09 +0800, Frank Li wrote:
> 2012/11/8 Ben Hutchings <bhutchings@solarflare.com>:
> > On Wed, 2012-11-07 at 10:52 +0800, Frank Li wrote:
> >> Richard:
> >>
> >> Recently, I found out the path delay will increase about
> >> 20us suddenly in something when connect two iMX6 board and Ethernet
> >> work on 1G mode.
> >> The reason is that the PHY enter lower mode automatically
> >> when no package send and receive. It takes some time to recover and
> >> send out package by PHY but MAC think package have sent and sample
> >> time stamper.
> >> Do you meet such case? I can workaround it by two method
> >> 1. disable phy lower power feature.
> >> 2. add some dummy package before SYNC package.
> >
> > If this low power mode is related to EEE (Energy Efficient Ethernet)
> > then there are ethtool operations defined for configuring it, and you
> > could implement those.
>
> Yes, it is phy specific, called smart EEE, which compatible with IEEE 802.3az
> and can be used in legacy MAC without EEE.
>
> Do you have example about ethtool operations?
Look at the comments on struct ethtool_eee in <uapi/linux/ethtool.h>,
and the existing implementations:
drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] [trivial] isdn: Fix typo in drivers/isdn
From: Masanari Iida @ 2012-11-09 15:02 UTC (permalink / raw)
To: linux-kernel, trivial, isdn, netdev; +Cc: davem, Masanari Iida
Correct spelling typo in printk within drivers/isdn
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
drivers/isdn/hardware/mISDN/hfcpci.c | 2 +-
drivers/isdn/hardware/mISDN/mISDNisar.c | 2 +-
drivers/isdn/hisax/callc.c | 2 +-
drivers/isdn/hisax/hfc_pci.c | 2 +-
drivers/isdn/hisax/hfc_sx.c | 2 +-
drivers/isdn/pcbit/layer2.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/isdn/hardware/mISDN/hfcpci.c b/drivers/isdn/hardware/mISDN/hfcpci.c
index 81363ff..6e99d73 100644
--- a/drivers/isdn/hardware/mISDN/hfcpci.c
+++ b/drivers/isdn/hardware/mISDN/hfcpci.c
@@ -490,7 +490,7 @@ receive_dmsg(struct hfc_pci *hc)
(df->data[le16_to_cpu(zp->z1)])) {
if (dch->debug & DEBUG_HW)
printk(KERN_DEBUG
- "empty_fifo hfcpci paket inv. len "
+ "empty_fifo hfcpci packet inv. len "
"%d or crc %d\n",
rcnt,
df->data[le16_to_cpu(zp->z1)]);
diff --git a/drivers/isdn/hardware/mISDN/mISDNisar.c b/drivers/isdn/hardware/mISDN/mISDNisar.c
index 182ecf0..feafa91 100644
--- a/drivers/isdn/hardware/mISDN/mISDNisar.c
+++ b/drivers/isdn/hardware/mISDN/mISDNisar.c
@@ -1302,7 +1302,7 @@ modeisar(struct isar_ch *ch, u32 bprotocol)
&ch->is->Flags))
ch->dpath = 1;
else {
- pr_info("modeisar both pathes in use\n");
+ pr_info("modeisar both paths in use\n");
return -EBUSY;
}
if (bprotocol == ISDN_P_B_HDLC)
diff --git a/drivers/isdn/hisax/callc.c b/drivers/isdn/hisax/callc.c
index a47637b..ddec47a 100644
--- a/drivers/isdn/hisax/callc.c
+++ b/drivers/isdn/hisax/callc.c
@@ -35,7 +35,7 @@ static int chancount;
/* experimental REJECT after ALERTING for CALLBACK to beat the 4s delay */
#define ALERT_REJECT 0
-/* Value to delay the sending of the first B-channel paket after CONNECT
+/* Value to delay the sending of the first B-channel packet after CONNECT
* here is no value given by ITU, but experience shows that 300 ms will
* work on many networks, if you or your other side is behind local exchanges
* a greater value may be recommented. If the delay is to short the first paket
diff --git a/drivers/isdn/hisax/hfc_pci.c b/drivers/isdn/hisax/hfc_pci.c
index 334fa90..f60d4be 100644
--- a/drivers/isdn/hisax/hfc_pci.c
+++ b/drivers/isdn/hisax/hfc_pci.c
@@ -354,7 +354,7 @@ receive_dmsg(struct IsdnCardState *cs)
if ((rcnt > MAX_DFRAME_LEN + 3) || (rcnt < 4) ||
(df->data[zp->z1])) {
if (cs->debug & L1_DEB_WARN)
- debugl1(cs, "empty_fifo hfcpci paket inv. len %d or crc %d", rcnt, df->data[zp->z1]);
+ debugl1(cs, "empty_fifo hfcpci packet inv. len %d or crc %d", rcnt, df->data[zp->z1]);
#ifdef ERROR_STATISTIC
cs->err_rx++;
#endif
diff --git a/drivers/isdn/hisax/hfc_sx.c b/drivers/isdn/hisax/hfc_sx.c
index 4db846b..4ec279c 100644
--- a/drivers/isdn/hisax/hfc_sx.c
+++ b/drivers/isdn/hisax/hfc_sx.c
@@ -270,7 +270,7 @@ read_fifo(struct IsdnCardState *cs, u_char fifo, int trans_max)
if ((count > fifo_size) || (count < 4)) {
if (cs->debug & L1_DEB_WARN)
- debugl1(cs, "hfcsx_read_fifo %d paket inv. len %d ", fifo , count);
+ debugl1(cs, "hfcsx_read_fifo %d packet inv. len %d ", fifo , count);
while (count) {
count--; /* empty fifo */
Read_hfc(cs, HFCSX_FIF_DRD);
diff --git a/drivers/isdn/pcbit/layer2.c b/drivers/isdn/pcbit/layer2.c
index a18e639..42ecfef 100644
--- a/drivers/isdn/pcbit/layer2.c
+++ b/drivers/isdn/pcbit/layer2.c
@@ -508,7 +508,7 @@ pcbit_irq_handler(int interrupt, void *devptr)
return IRQ_NONE;
}
if (dev->interrupt) {
- printk(KERN_DEBUG "pcbit: reentering interrupt hander\n");
+ printk(KERN_DEBUG "pcbit: reentering interrupt handler\n");
return IRQ_HANDLED;
}
dev->interrupt = 1;
--
1.8.0.rc3.16.g8ead1bf
^ permalink raw reply related
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