* [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] 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
* 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
* 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 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: 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: 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: [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: 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: 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: 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
* 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: 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
* 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: 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: Yuchung Cheng @ 2012-11-09 18:53 UTC (permalink / raw)
To: Vincent Li; +Cc: Vijay Subramanian, netdev
In-Reply-To: <CAK3+h2z5=n6BHGzPjfbrJS4MbVGQ2pdMQP54dOZ8M=8xigUd3Q@mail.gmail.com>
On Fri, Nov 9, 2012 at 1:47 PM, Vincent Li <vincent.mc.li@gmail.com> wrote:
> 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.
Hi Vincent,
Note that MSG_FASTOPEN flag should be used only once. Subsequent
sendto(MSG_FASTOPEN) == connect() on connected sockets. You can verify
if the fast open is successful by checking a bit in TCP_INFO.
http://patchwork.o zlabs.org/patch/192883/ if you are running a fresh
netdev build.
I'll submit a patch to update the man page on MSG_FASTOPEN too.
Yuchung
>
> Vincent
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] ipv6: export IP6_RT_PRIO_* to userland
From: David Miller @ 2012-11-09 19:05 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <509CD046.4060302@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 09 Nov 2012 10:43:34 +0100
> Le 05/11/2012 20:24, Nicolas Dichtel a écrit :
>> Le 05/11/2012 18:43, David Miller a écrit :
>>> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>> Date: Mon, 05 Nov 2012 18:22:39 +0100
>>>
>>>> Le 05/11/2012 18:00, David Miller a écrit :
>>>>> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>>>> Date: Mon, 5 Nov 2012 16:28:18 +0100
>>>>>
>>>>>> The kernel uses some default metric when routes are managed. For
>>>>>> example, a
>>>>>> static route added with a metric set to 0 is inserted in the kernel
>>>>>> with
>>>>>> metric 1024 (IP6_RT_PRIO_USER).
>>>>>> It is useful for routing daemons to know these values, to be able to
>>>>>> set routes
>>>>>> without interfering with what the kernel does.
>>>>>>
>>>>>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>>>>
>>>>> But these belong in the libc headers anyways.
>>>>>
>>>>> If we haven't provided them for so long, there's no real value of
>>>>> adding them now.
>>>>>
>>>> But how can a daemon know which default values are used? If it wants
>>>> to add a route with metric = default + x, it should first add it with
>>>> metric = 0, check the result and then change the metric.
>>>
>>> What do we do on the ipv4 side and how do daemons cope in that
>>> situation?
>>>
>> In IPv4, there is no such default metric. If you add a route with
>> metric X, it
>> remains X in the kernel, even if it's 0.
> So we need to duplicate these values in the daemon?
>
I'm without real internet access again for the past 2 days and simply
too backlogged to even continue considering this issue.
Please be patient.
^ permalink raw reply
* [PATCH] r8169: Kill RX_BUF_SIZE macro
From: Kirill Smelkov @ 2012-11-09 19:29 UTC (permalink / raw)
To: Francois Romieu
Cc: Realtek linux nic maintainers, netdev, Kirill Smelkov,
Eric Dumazet
After 6f0333b8 (r8169: use 50% less ram for RX ring) RX_BUF_SIZE is not
used and should be gone.
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Kirill Smelkov <kirr@navytux.spb.ru>
---
drivers/net/ethernet/realtek/r8169.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index d6c6cfb..029a028 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -84,7 +84,6 @@ static const int multicast_filter_limit = 32;
#define R8169_NAPI_WEIGHT 64
#define NUM_TX_DESC 64 /* Number of Tx descriptor registers */
#define NUM_RX_DESC 256 /* Number of Rx descriptor registers */
-#define RX_BUF_SIZE 1536 /* Rx Buffer size */
#define R8169_TX_RING_BYTES (NUM_TX_DESC * sizeof(struct TxDesc))
#define R8169_RX_RING_BYTES (NUM_RX_DESC * sizeof(struct RxDesc))
--
1.8.0.337.g4cdca5d
^ permalink raw reply related
* Re: question on netdev_completed_queue()
From: Eric Dumazet @ 2012-11-09 19:38 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Oliver Neukum, netdev
In-Reply-To: <1352480979.3159.13.camel@bwh-desktop.uk.solarflarecom.com>
On Fri, 2012-11-09 at 17:09 +0000, Ben Hutchings wrote:
> 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.
Yes, skb->len should be a fine approximation, even if slightly wrong for
TSO packets.
^ permalink raw reply
* Re: [PATCH net-next 1/3] ipip: advertise tunnel param via rtnl
From: Eric Dumazet @ 2012-11-09 19:42 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, davem
In-Reply-To: <509D36CB.9030509@6wind.com>
On Fri, 2012-11-09 at 18:00 +0100, Nicolas Dichtel wrote:
> 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, ...).
The principle is already used for gre tunnels, so it definitely is
approved ;)
^ permalink raw reply
* Re: [PATCH v3 1/9] net: core: use this_cpu_ptr per-cpu helper
From: Christoph Lameter @ 2012-11-09 20:08 UTC (permalink / raw)
To: Shan Wei
Cc: David Miller, timo.teras, steffen.klassert, NetDev,
Kernel-Maillist
In-Reply-To: <509C686F.20400@gmail.com>
On Fri, 9 Nov 2012, Shan Wei wrote:
> diff --git a/net/core/flow.c b/net/core/flow.c
> index e318c7e..b0901ee 100644
> --- a/net/core/flow.c
> +++ b/net/core/flow.c
> @@ -327,11 +327,9 @@ static void flow_cache_flush_tasklet(unsigned long data)
> static void flow_cache_flush_per_cpu(void *data)
> {
> struct flow_flush_info *info = data;
> - int cpu;
> struct tasklet_struct *tasklet;
>
> - cpu = smp_processor_id();
> - tasklet = &per_cpu_ptr(info->cache->percpu, cpu)->flush_tasklet;
> + tasklet = this_cpu_ptr(&info->cache->percpu->flush_tasklet);
> tasklet->data = (unsigned long)info;
this_cpu_write(info->cache->percpu->flush_tasklet->data, (unsigned
long)info);
should also do the trick in less instructions and get rid of all temporary
variables as well.
^ permalink raw reply
* Re: [PATCH v3 2/9] net: rds: use this_cpu_ptr per-cpu helper
From: Christoph Lameter @ 2012-11-09 20:09 UTC (permalink / raw)
To: Shan Wei
Cc: venkat.x.venkatsubra, David Miller, rds-devel, NetDev,
Kernel-Maillist
In-Reply-To: <509C687E.1080106@gmail.com>
On Fri, 9 Nov 2012, Shan Wei wrote:
> net/rds/ib_recv.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c
> index 8d19491..a4a5064 100644
> --- a/net/rds/ib_recv.c
> +++ b/net/rds/ib_recv.c
> @@ -423,7 +423,7 @@ static void rds_ib_recv_cache_put(struct list_head *new_item,
>
> local_irq_save(flags);
>
> - chp = per_cpu_ptr(cache->percpu, smp_processor_id());
> + chp = this_cpu_ptr(cache->percpu);
> if (!chp->first)
if (!__this_cpu_read(cache-0>percpu->first))
?
^ permalink raw reply
* Re: [PATCH v3 3/9] net: xfrm: use __this_cpu_read per-cpu helper
From: Christoph Lameter @ 2012-11-09 20:12 UTC (permalink / raw)
To: Shan Wei
Cc: steffen.klassert, David Miller, NetDev, Herbert Xu,
Kernel-Maillist
In-Reply-To: <509C688B.5010502@gmail.com>
On Fri, 9 Nov 2012, Shan Wei wrote:
> v3 fix compile warning:
> net/xfrm/xfrm_ipcomp.c: In function 'ipcomp_alloc_tfms':
> net/xfrm/xfrm_ipcomp.c:285: warning: assignment from incompatible pointer type
Why exactly is the pointer type not compatible? Looks like we have a
problem here.
^ permalink raw reply
* Re: [PATCH v3 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper
From: Christoph Lameter @ 2012-11-09 20:12 UTC (permalink / raw)
To: Shan Wei
Cc: dev-yBygre7rU0TnMu66kgdUjQ, NetDev, Kernel-Maillist, David Miller
In-Reply-To: <509C6895.6020300-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, 9 Nov 2012, Shan Wei wrote:
> just use more faster this_cpu_ptr instead of per_cpu_ptr(p, smp_processor_id());
Reviewed-by: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v3 1/9] net: core: use this_cpu_ptr per-cpu helper
From: Eric Dumazet @ 2012-11-09 20:15 UTC (permalink / raw)
To: Christoph Lameter
Cc: Shan Wei, David Miller, timo.teras, steffen.klassert, NetDev,
Kernel-Maillist
In-Reply-To: <0000013ae6c9e81a-eabe295b-72a5-4ebd-85c5-231bec1a70c5-000000@email.amazonses.com>
On Fri, 2012-11-09 at 20:08 +0000, Christoph Lameter wrote:
> On Fri, 9 Nov 2012, Shan Wei wrote:
>
> > diff --git a/net/core/flow.c b/net/core/flow.c
> > index e318c7e..b0901ee 100644
> > --- a/net/core/flow.c
> > +++ b/net/core/flow.c
> > @@ -327,11 +327,9 @@ static void flow_cache_flush_tasklet(unsigned long data)
> > static void flow_cache_flush_per_cpu(void *data)
> > {
> > struct flow_flush_info *info = data;
> > - int cpu;
> > struct tasklet_struct *tasklet;
> >
> > - cpu = smp_processor_id();
> > - tasklet = &per_cpu_ptr(info->cache->percpu, cpu)->flush_tasklet;
> > + tasklet = this_cpu_ptr(&info->cache->percpu->flush_tasklet);
> > tasklet->data = (unsigned long)info;
>
> this_cpu_write(info->cache->percpu->flush_tasklet->data, (unsigned
> long)info);
>
> should also do the trick in less instructions and get rid of all temporary
> variables as well.
Its not the case.
We need the _pointer_ to call :
tasklet_schedule(tasklet);
^ 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