* [PATCH net-next 2/3] cxgb4: report the PCIe link speed
From: Dimitris Michailidis @ 2010-05-11 1:58 UTC (permalink / raw)
To: netdev; +Cc: Dimitris Michailidis
In-Reply-To: <1273543089-10938-1-git-send-email-dm@chelsio.com>
Report the PCIe link speed (2.5 or 5 Gbps).
Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
---
drivers/net/cxgb4/cxgb4_main.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/cxgb4/cxgb4_main.c b/drivers/net/cxgb4/cxgb4_main.c
index a73cda9..80c3fc5 100644
--- a/drivers/net/cxgb4/cxgb4_main.c
+++ b/drivers/net/cxgb4/cxgb4_main.c
@@ -3080,6 +3080,12 @@ static void __devinit print_port_info(struct adapter *adap)
int i;
char buf[80];
+ const char *spd = "";
+
+ if (adap->params.pci.speed == PCI_EXP_LNKSTA_CLS_2_5GB)
+ spd = " 2.5 GT/s";
+ else if (adap->params.pci.speed == PCI_EXP_LNKSTA_CLS_5_0GB)
+ spd = " 5 GT/s";
for_each_port(adap, i) {
struct net_device *dev = adap->port[i];
@@ -3099,10 +3105,10 @@ static void __devinit print_port_info(struct adapter *adap)
--bufp;
sprintf(bufp, "BASE-%s", base[pi->port_type]);
- netdev_info(dev, "Chelsio %s rev %d %s %sNIC PCIe x%d%s\n",
+ netdev_info(dev, "Chelsio %s rev %d %s %sNIC PCIe x%d%s%s\n",
adap->params.vpd.id, adap->params.rev,
buf, is_offload(adap) ? "R" : "",
- adap->params.pci.width,
+ adap->params.pci.width, spd,
(adap->flags & USING_MSIX) ? " MSI-X" :
(adap->flags & USING_MSI) ? " MSI" : "");
if (adap->name == dev->name)
--
1.5.4
^ permalink raw reply related
* [PATCH net-next 3/3] cxgb4: report GRO stats with ethtool -S
From: Dimitris Michailidis @ 2010-05-11 1:58 UTC (permalink / raw)
To: netdev; +Cc: Dimitris Michailidis
In-Reply-To: <1273543089-10938-2-git-send-email-dm@chelsio.com>
Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
---
drivers/net/cxgb4/cxgb4_main.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb4/cxgb4_main.c b/drivers/net/cxgb4/cxgb4_main.c
index 80c3fc5..90d375b 100644
--- a/drivers/net/cxgb4/cxgb4_main.c
+++ b/drivers/net/cxgb4/cxgb4_main.c
@@ -859,6 +859,8 @@ static char stats_strings[][ETH_GSTRING_LEN] = {
"RxCsumGood ",
"VLANextractions ",
"VLANinsertions ",
+ "GROpackets ",
+ "GROmerged ",
};
static int get_sset_count(struct net_device *dev, int sset)
@@ -922,6 +924,8 @@ struct queue_port_stats {
u64 rx_csum;
u64 vlan_ex;
u64 vlan_ins;
+ u64 gro_pkts;
+ u64 gro_merged;
};
static void collect_sge_port_stats(const struct adapter *adap,
@@ -938,6 +942,8 @@ static void collect_sge_port_stats(const struct adapter *adap,
s->rx_csum += rx->stats.rx_cso;
s->vlan_ex += rx->stats.vlan_ex;
s->vlan_ins += tx->vlan_ins;
+ s->gro_pkts += rx->stats.lro_pkts;
+ s->gro_merged += rx->stats.lro_merged;
}
}
--
1.5.4
^ permalink raw reply related
* [PATCH net-next 1/3] cxgb4: configure HW VLAN extraction through FW
From: Dimitris Michailidis @ 2010-05-11 1:58 UTC (permalink / raw)
To: netdev; +Cc: Dimitris Michailidis
HW VLAN extraction needs to be configured through FW to work correctly in
virtualization environments. Remove the direct register manipulation and
rely on FW.
Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
---
drivers/net/cxgb4/cxgb4.h | 4 ++--
drivers/net/cxgb4/cxgb4_main.c | 9 +++++----
drivers/net/cxgb4/t4_hw.c | 31 ++++++++++---------------------
drivers/net/cxgb4/t4fw_api.h | 4 +++-
4 files changed, 20 insertions(+), 28 deletions(-)
diff --git a/drivers/net/cxgb4/cxgb4.h b/drivers/net/cxgb4/cxgb4.h
index 8856a75..d3a5c34 100644
--- a/drivers/net/cxgb4/cxgb4.h
+++ b/drivers/net/cxgb4/cxgb4.h
@@ -656,7 +656,6 @@ int t4_check_fw_version(struct adapter *adapter);
int t4_prep_adapter(struct adapter *adapter);
int t4_port_init(struct adapter *adap, int mbox, int pf, int vf);
void t4_fatal_err(struct adapter *adapter);
-void t4_set_vlan_accel(struct adapter *adapter, unsigned int ports, int on);
int t4_set_trace_filter(struct adapter *adapter, const struct trace_params *tp,
int filter_index, int enable);
void t4_get_trace_filter(struct adapter *adapter, struct trace_params *tp,
@@ -707,7 +706,8 @@ int t4_alloc_vi(struct adapter *adap, unsigned int mbox, unsigned int port,
int t4_free_vi(struct adapter *adap, unsigned int mbox, unsigned int pf,
unsigned int vf, unsigned int viid);
int t4_set_rxmode(struct adapter *adap, unsigned int mbox, unsigned int viid,
- int mtu, int promisc, int all_multi, int bcast, bool sleep_ok);
+ int mtu, int promisc, int all_multi, int bcast, int vlanex,
+ bool sleep_ok);
int t4_alloc_mac_filt(struct adapter *adap, unsigned int mbox,
unsigned int viid, bool free, unsigned int naddr,
const u8 **addr, u16 *idx, u64 *hash, bool sleep_ok);
diff --git a/drivers/net/cxgb4/cxgb4_main.c b/drivers/net/cxgb4/cxgb4_main.c
index 1bad500..a73cda9 100644
--- a/drivers/net/cxgb4/cxgb4_main.c
+++ b/drivers/net/cxgb4/cxgb4_main.c
@@ -290,7 +290,7 @@ static int set_rxmode(struct net_device *dev, int mtu, bool sleep_ok)
if (ret == 0)
ret = t4_set_rxmode(pi->adapter, 0, pi->viid, mtu,
(dev->flags & IFF_PROMISC) ? 1 : 0,
- (dev->flags & IFF_ALLMULTI) ? 1 : 0, 1,
+ (dev->flags & IFF_ALLMULTI) ? 1 : 0, 1, -1,
sleep_ok);
return ret;
}
@@ -311,7 +311,7 @@ static int link_start(struct net_device *dev)
* that step explicitly.
*/
ret = t4_set_rxmode(pi->adapter, 0, pi->viid, dev->mtu, -1, -1, -1,
- true);
+ pi->vlan_grp != NULL, true);
if (ret == 0) {
ret = t4_change_mac(pi->adapter, 0, pi->viid,
pi->xact_addr_filt, dev->dev_addr, true,
@@ -2614,7 +2614,7 @@ static int cxgb_change_mtu(struct net_device *dev, int new_mtu)
if (new_mtu < 81 || new_mtu > MAX_MTU) /* accommodate SACK */
return -EINVAL;
- ret = t4_set_rxmode(pi->adapter, 0, pi->viid, new_mtu, -1, -1, -1,
+ ret = t4_set_rxmode(pi->adapter, 0, pi->viid, new_mtu, -1, -1, -1, -1,
true);
if (!ret)
dev->mtu = new_mtu;
@@ -2645,7 +2645,8 @@ static void vlan_rx_register(struct net_device *dev, struct vlan_group *grp)
struct port_info *pi = netdev_priv(dev);
pi->vlan_grp = grp;
- t4_set_vlan_accel(pi->adapter, 1 << pi->tx_chan, grp != NULL);
+ t4_set_rxmode(pi->adapter, 0, pi->viid, -1, -1, -1, -1, grp != NULL,
+ true);
}
#ifdef CONFIG_NET_POLL_CONTROLLER
diff --git a/drivers/net/cxgb4/t4_hw.c b/drivers/net/cxgb4/t4_hw.c
index 2923dd4..da272a9 100644
--- a/drivers/net/cxgb4/t4_hw.c
+++ b/drivers/net/cxgb4/t4_hw.c
@@ -886,22 +886,6 @@ int t4_restart_aneg(struct adapter *adap, unsigned int mbox, unsigned int port)
return t4_wr_mbox(adap, mbox, &c, sizeof(c), NULL);
}
-/**
- * t4_set_vlan_accel - configure HW VLAN extraction
- * @adap: the adapter
- * @ports: bitmap of adapter ports to operate on
- * @on: enable (1) or disable (0) HW VLAN extraction
- *
- * Enables or disables HW extraction of VLAN tags for the ports specified
- * by @ports. @ports is a bitmap with the ith bit designating the port
- * associated with the ith adapter channel.
- */
-void t4_set_vlan_accel(struct adapter *adap, unsigned int ports, int on)
-{
- ports <<= VLANEXTENABLE_SHIFT;
- t4_set_reg_field(adap, TP_OUT_CONFIG, ports, on ? ports : 0);
-}
-
struct intr_info {
unsigned int mask; /* bits to check in interrupt status */
const char *msg; /* message to print or NULL */
@@ -2624,12 +2608,14 @@ int t4_free_vi(struct adapter *adap, unsigned int mbox, unsigned int pf,
* @promisc: 1 to enable promiscuous mode, 0 to disable it, -1 no change
* @all_multi: 1 to enable all-multi mode, 0 to disable it, -1 no change
* @bcast: 1 to enable broadcast Rx, 0 to disable it, -1 no change
+ * @vlanex: 1 to enable HW VLAN extraction, 0 to disable it, -1 no change
* @sleep_ok: if true we may sleep while awaiting command completion
*
* Sets Rx properties of a virtual interface.
*/
int t4_set_rxmode(struct adapter *adap, unsigned int mbox, unsigned int viid,
- int mtu, int promisc, int all_multi, int bcast, bool sleep_ok)
+ int mtu, int promisc, int all_multi, int bcast, int vlanex,
+ bool sleep_ok)
{
struct fw_vi_rxmode_cmd c;
@@ -2642,15 +2628,18 @@ int t4_set_rxmode(struct adapter *adap, unsigned int mbox, unsigned int viid,
all_multi = FW_VI_RXMODE_CMD_ALLMULTIEN_MASK;
if (bcast < 0)
bcast = FW_VI_RXMODE_CMD_BROADCASTEN_MASK;
+ if (vlanex < 0)
+ vlanex = FW_VI_RXMODE_CMD_VLANEXEN_MASK;
memset(&c, 0, sizeof(c));
c.op_to_viid = htonl(FW_CMD_OP(FW_VI_RXMODE_CMD) | FW_CMD_REQUEST |
FW_CMD_WRITE | FW_VI_RXMODE_CMD_VIID(viid));
c.retval_len16 = htonl(FW_LEN16(c));
- c.mtu_to_broadcasten = htonl(FW_VI_RXMODE_CMD_MTU(mtu) |
- FW_VI_RXMODE_CMD_PROMISCEN(promisc) |
- FW_VI_RXMODE_CMD_ALLMULTIEN(all_multi) |
- FW_VI_RXMODE_CMD_BROADCASTEN(bcast));
+ c.mtu_to_vlanexen = htonl(FW_VI_RXMODE_CMD_MTU(mtu) |
+ FW_VI_RXMODE_CMD_PROMISCEN(promisc) |
+ FW_VI_RXMODE_CMD_ALLMULTIEN(all_multi) |
+ FW_VI_RXMODE_CMD_BROADCASTEN(bcast) |
+ FW_VI_RXMODE_CMD_VLANEXEN(vlanex));
return t4_wr_mbox_meat(adap, mbox, &c, sizeof(c), NULL, sleep_ok);
}
diff --git a/drivers/net/cxgb4/t4fw_api.h b/drivers/net/cxgb4/t4fw_api.h
index 3393d05..63991d6 100644
--- a/drivers/net/cxgb4/t4fw_api.h
+++ b/drivers/net/cxgb4/t4fw_api.h
@@ -876,7 +876,7 @@ struct fw_vi_mac_cmd {
struct fw_vi_rxmode_cmd {
__be32 op_to_viid;
__be32 retval_len16;
- __be32 mtu_to_broadcasten;
+ __be32 mtu_to_vlanexen;
__be32 r4_lo;
};
@@ -888,6 +888,8 @@ struct fw_vi_rxmode_cmd {
#define FW_VI_RXMODE_CMD_ALLMULTIEN(x) ((x) << 12)
#define FW_VI_RXMODE_CMD_BROADCASTEN_MASK 0x3
#define FW_VI_RXMODE_CMD_BROADCASTEN(x) ((x) << 10)
+#define FW_VI_RXMODE_CMD_VLANEXEN_MASK 0x3
+#define FW_VI_RXMODE_CMD_VLANEXEN(x) ((x) << 8)
struct fw_vi_enable_cmd {
__be32 op_to_viid;
--
1.5.4
^ permalink raw reply related
* Re: [PATCH net-next 3/3] cxgb4: report GRO stats with ethtool -S
From: Ben Greear @ 2010-05-11 3:02 UTC (permalink / raw)
To: Dimitris Michailidis; +Cc: netdev
In-Reply-To: <1273543089-10938-3-git-send-email-dm@chelsio.com>
On 05/10/2010 06:58 PM, Dimitris Michailidis wrote:
> Signed-off-by: Dimitris Michailidis<dm@chelsio.com>
One of these is on-wire packets? If so, maybe use the same
string as Intel ixgbe uses:
rx_pkts_nic # Pkts received by NIC from wire.
rx_bytes_nic # Bytes received by NIC from wire.
tx_pkts_nic # Pkts transmitted to wire by NIC.
tx_bytes_nic # Bytes transmitted to wire by NIC.
Thanks,
Ben
> ---
> drivers/net/cxgb4/cxgb4_main.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/cxgb4/cxgb4_main.c b/drivers/net/cxgb4/cxgb4_main.c
> index 80c3fc5..90d375b 100644
> --- a/drivers/net/cxgb4/cxgb4_main.c
> +++ b/drivers/net/cxgb4/cxgb4_main.c
> @@ -859,6 +859,8 @@ static char stats_strings[][ETH_GSTRING_LEN] = {
> "RxCsumGood ",
> "VLANextractions ",
> "VLANinsertions ",
> + "GROpackets ",
> + "GROmerged ",
> };
>
> static int get_sset_count(struct net_device *dev, int sset)
> @@ -922,6 +924,8 @@ struct queue_port_stats {
> u64 rx_csum;
> u64 vlan_ex;
> u64 vlan_ins;
> + u64 gro_pkts;
> + u64 gro_merged;
> };
>
> static void collect_sge_port_stats(const struct adapter *adap,
> @@ -938,6 +942,8 @@ static void collect_sge_port_stats(const struct adapter *adap,
> s->rx_csum += rx->stats.rx_cso;
> s->vlan_ex += rx->stats.vlan_ex;
> s->vlan_ins += tx->vlan_ins;
> + s->gro_pkts += rx->stats.lro_pkts;
> + s->gro_merged += rx->stats.lro_merged;
> }
> }
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 40/84] netfilter: ipvs: use NFPROTO values for NF_HOOK invocation
From: Simon Horman @ 2010-05-11 3:07 UTC (permalink / raw)
To: kaber; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <1273522735-24672-41-git-send-email-kaber@trash.net>
On Mon, May 10, 2010 at 10:18:11PM +0200, kaber@trash.net wrote:
> From: Jan Engelhardt <jengelh@medozas.de>
>
> Semantic patch:
> // <smpl>
> @@
> @@
> IP_VS_XMIT(
> -PF_INET6,
> +NFPROTO_IPV6,
> ...)
>
> @@
> @@
> IP_VS_XMIT(
> -PF_INET,
> +NFPROTO_IPV4,
> ...)
> // </smpl>
>
> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
FWIW
Acked-by: Simon Horman <horms@verge.net.au>
> ---
> net/netfilter/ipvs/ip_vs_xmit.c | 16 ++++++++--------
> 1 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
> index 223b501..d0a7b7b 100644
> --- a/net/netfilter/ipvs/ip_vs_xmit.c
> +++ b/net/netfilter/ipvs/ip_vs_xmit.c
> @@ -269,7 +269,7 @@ ip_vs_bypass_xmit(struct sk_buff *skb, struct ip_vs_conn *cp,
> /* Another hack: avoid icmp_send in ip_fragment */
> skb->local_df = 1;
>
> - IP_VS_XMIT(PF_INET, skb, rt);
> + IP_VS_XMIT(NFPROTO_IPV4, skb, rt);
>
> LeaveFunction(10);
> return NF_STOLEN;
> @@ -333,7 +333,7 @@ ip_vs_bypass_xmit_v6(struct sk_buff *skb, struct ip_vs_conn *cp,
> /* Another hack: avoid icmp_send in ip_fragment */
> skb->local_df = 1;
>
> - IP_VS_XMIT(PF_INET6, skb, rt);
> + IP_VS_XMIT(NFPROTO_IPV6, skb, rt);
>
> LeaveFunction(10);
> return NF_STOLEN;
> @@ -409,7 +409,7 @@ ip_vs_nat_xmit(struct sk_buff *skb, struct ip_vs_conn *cp,
> /* Another hack: avoid icmp_send in ip_fragment */
> skb->local_df = 1;
>
> - IP_VS_XMIT(PF_INET, skb, rt);
> + IP_VS_XMIT(NFPROTO_IPV4, skb, rt);
>
> LeaveFunction(10);
> return NF_STOLEN;
> @@ -485,7 +485,7 @@ ip_vs_nat_xmit_v6(struct sk_buff *skb, struct ip_vs_conn *cp,
> /* Another hack: avoid icmp_send in ip_fragment */
> skb->local_df = 1;
>
> - IP_VS_XMIT(PF_INET6, skb, rt);
> + IP_VS_XMIT(NFPROTO_IPV6, skb, rt);
>
> LeaveFunction(10);
> return NF_STOLEN;
> @@ -784,7 +784,7 @@ ip_vs_dr_xmit(struct sk_buff *skb, struct ip_vs_conn *cp,
> /* Another hack: avoid icmp_send in ip_fragment */
> skb->local_df = 1;
>
> - IP_VS_XMIT(PF_INET, skb, rt);
> + IP_VS_XMIT(NFPROTO_IPV4, skb, rt);
>
> LeaveFunction(10);
> return NF_STOLEN;
> @@ -837,7 +837,7 @@ ip_vs_dr_xmit_v6(struct sk_buff *skb, struct ip_vs_conn *cp,
> /* Another hack: avoid icmp_send in ip_fragment */
> skb->local_df = 1;
>
> - IP_VS_XMIT(PF_INET6, skb, rt);
> + IP_VS_XMIT(NFPROTO_IPV6, skb, rt);
>
> LeaveFunction(10);
> return NF_STOLEN;
> @@ -911,7 +911,7 @@ ip_vs_icmp_xmit(struct sk_buff *skb, struct ip_vs_conn *cp,
> /* Another hack: avoid icmp_send in ip_fragment */
> skb->local_df = 1;
>
> - IP_VS_XMIT(PF_INET, skb, rt);
> + IP_VS_XMIT(NFPROTO_IPV4, skb, rt);
>
> rc = NF_STOLEN;
> goto out;
> @@ -986,7 +986,7 @@ ip_vs_icmp_xmit_v6(struct sk_buff *skb, struct ip_vs_conn *cp,
> /* Another hack: avoid icmp_send in ip_fragment */
> skb->local_df = 1;
>
> - IP_VS_XMIT(PF_INET6, skb, rt);
> + IP_VS_XMIT(NFPROTO_IPV6, skb, rt);
>
> rc = NF_STOLEN;
> goto out;
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: e1000e fails probe
From: Pete Zaitcev @ 2010-05-11 3:55 UTC (permalink / raw)
To: Allan, Bruce W; +Cc: netdev@vger.kernel.org
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A90010D1DE754@orsmsx509.amr.corp.intel.com>
On Mon, 10 May 2010 18:33:56 -0700
"Allan, Bruce W" <bruce.w.allan@intel.com> wrote:
> Sorry you are having problems with e1000e. You didn't mention which
> LOM device was on this system - is the PCI device id 0x10ea, 0x10eb,
> 0x10ef or 0x10f0?
lspci -n says:
00:19.0 0200: 8086:10ef (rev 04)
> What BIOS version is on the system?
dmidecode says:
Vendor: American Megatrends Inc.
Version: 4.6.3
Release Date: 05/22/2009
> Would you be able to try a patch that is already in DaveM's net-next-2.6
> tree? If so, it is
> http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commitdiff;h=627c8a041f7aaaea93c766f69bd61d952a277586
Thank you, this works. I guess I should've been more patient.
Yours,
-- Pete
^ permalink raw reply
* Re: TCP-MD5 checksum failure on x86_64 SMP
From: Bijay Singh @ 2010-05-11 4:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Hemminger, David Miller, <bhaskie@gmail.com>,
<bhutchings@solarflare.com>, <netdev@vger.kernel.org>
In-Reply-To: <1273504693.2221.17.camel@edumazet-laptop>
Hi Eric,
I guess that makes me the enviable one. So I am keen to test out this feature completely, as long as I know what to do as a next step, directions, patches.
Thanks,
Bijay
On 10-May-2010, at 8:48 PM, Eric Dumazet wrote:
> Le lundi 10 mai 2010 à 14:55 +0000, Bijay Singh a écrit :
>> Hi,
>> I had noticed the corruption in the context and actually did what is mentioned.
>>
>> I allocated the context on the stack and plugged in the md5.c functions. I was able to temporarily solve the problem, all this before I got a response on this thread.
>>
>> But now I have seeing another problem, when i change the MTU on the interface from 1500 to 4470 none of the message from the peer get thru and I get hash failed message. I am wondering if this is another bug getting hit in this scenario.
>
> Thats very fine, but you mix very different problems.
>
> Step by step resolution is required, and clean patches too, because
> plugging md5.c functions is not an option for stable series :)
>
> Obviously, nobody seriously used TCP-MD5 on linux, but you...
>
>
>
^ permalink raw reply
* Re: e1000e fails probe
From: Pete Zaitcev @ 2010-05-11 4:43 UTC (permalink / raw)
To: Allan, Bruce W; +Cc: netdev@vger.kernel.org, zaitcev
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A90010D1DE754@orsmsx509.amr.corp.intel.com>
On Mon, 10 May 2010 18:33:56 -0700
"Allan, Bruce W" <bruce.w.allan@intel.com> wrote:
> Would you be able to try a patch that is already in DaveM's net-next-2.6 tree? If so, it is http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commitdiff;h=627c8a041f7aaaea93c766f69bd61d952a277586
I was too quick to claim victory here. I did an rmmod+insmod,
it worked. Then I rebooted and it didn't. Weird...
-- Pete
^ permalink raw reply
* Re: Question about more headroom in skb
From: Eric Dumazet @ 2010-05-11 5:06 UTC (permalink / raw)
To: Sharat Masetty; +Cc: netdev, linux-kernel
In-Reply-To: <682359.68270.qm@web112510.mail.gq1.yahoo.com>
Le lundi 10 mai 2010 à 13:09 -0700, Sharat Masetty a écrit :
> Hello All,
Please dont use too long lines
>
> For my project I need 3 words of headroom in the skb in the network
> driver level, to add a custom header to the ethernet packet. I
> looked into the tcp code and figured out tcp uses sk->sk_prot->max_header
> for header allocation size. But I was not able to confirm that all other
> transport protocol use the same mechanism(?) For example in UDP/ICMP I was
> not able to figure out from the code where the allocation and header
> reservation happens(Any light here would be really helpful.)
>
> I have also looked at an API in skbuff skb_pad() which does what I want
> (add either headroom or tailroom), but I want to avoid that for performance
> reasons(skb_pad does kmalloc and memcpy). I want to figure out a good way
> (may be tune some parameters) to allocate extra 3 words for any skbuff
> independant of the transport protocol being used.
> Any light here would be very much appreciated.
LL_RESERVED_SPACE() is the magic you need.
#define LL_RESERVED_SPACE(dev) \
((((dev)->hard_header_len+(dev)->needed_headroom)&~(HH_DATA_MOD - 1)) + HH_DATA_MOD)
sendmsg() -> ip_append_data()
...
hh_len = LL_RESERVED_SPACE(rt->u.dst.dev);
fragheaderlen = sizeof(struct iphdr) + (opt ? opt->optlen : 0);
...
if (transhdrlen) {
skb = sock_alloc_send_skb(sk,
alloclen + hh_len + 15,
(flags & MSG_DONTWAIT), &err);
} else {
skb = NULL;
if (atomic_read(&sk->sk_wmem_alloc) <=
2 * sk->sk_sndbuf)
skb = sock_wmalloc(sk,
alloclen + hh_len + 15, 1,
sk->sk_allocation);
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-05-10
From: David Miller @ 2010-05-11 5:54 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100510174329.GC11681@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 10 May 2010 13:43:29 -0400
> Here are three more candidates for 2.6.34. I hesitated to push them,
> but at least two of them are documented regressions and the other (i.e.
> "iwlwifi: work around passive scan issue") avoids some rather annoying
> firmware restarts at little or no risk. I think it would be good to
> take these now rather than later.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: bug: micrel phy init (2.6.34-rc7)
From: David Miller @ 2010-05-11 5:55 UTC (permalink / raw)
To: randy.dunlap; +Cc: linux-kernel, netdev, david.choi
In-Reply-To: <4BE88F22.3060408@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 10 May 2010 15:56:34 -0700
> On 05/10/10 15:42, Randy Dunlap wrote:
>> Loading the micrel phy driver BUGs (no device present):
>>
>> [ 623.821462] BUG: unable to handle kernel NULL pointer dereference at (null)
>> [ 623.822164] IP: [<ffffffff8123c9f0>] strcmp+0x6/0x44
>> [ 623.822164] PGD 7d4bd067 PUD 7d6bb067 PMD 0
>> [ 623.822164] Oops: 0000 [#1] SMP
>>
>>
>> Full kernel log and config are attached.
>>
>> Not a regression -- this is a new driver.
>
> OK, I see that this was reported & fixed on May-06. :)
:-)
^ permalink raw reply
* Re: drivers/net/ RFC: Remove return; before void function end-of-functions close brace
From: David Miller @ 2010-05-11 5:58 UTC (permalink / raw)
To: joe; +Cc: netdev
In-Reply-To: <1273540476.20514.61.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Mon, 10 May 2010 18:14:36 -0700
> Anyone think such patches acceptable/useful?
Sure, if you want.
^ permalink raw reply
* Re: [PATCH 2/4 v2] ks8851: Low level functions for read/write to companion eeprom
From: David Miller @ 2010-05-11 5:59 UTC (permalink / raw)
To: ben-linux; +Cc: s-jan, netdev, linux-omap, x0066660, Tristram.Ha
In-Reply-To: <20100511012353.GJ2589@trinity.fluff.org>
From: Ben Dooks <ben-linux@fluff.org>
Date: Tue, 11 May 2010 02:23:54 +0100
> On Thu, May 06, 2010 at 12:20:12AM -0700, David Miller wrote:
>> From: Sebastien Jan <s-jan@ti.com>
>> Date: Wed, 5 May 2010 20:45:53 +0200
>>
>> > Low-level functions provide 16bits words read and write capability
>> > to ks8851 companion eeprom.
>> >
>> > Signed-off-by: Sebastien Jan <s-jan@ti.com>
>>
>> Applied.
>
> So I take it the patches that used the drivers/misc/eeprom/eeprom_93cx6.c
> are not going to be merged?
What makes you think that? Feel free to submit such a patch and find
out for real.
If you want things done differently from the start, review patches
faster :-)
^ permalink raw reply
* Re: [PATCH 00/84] netfilter: netfilter update for 2.6.35
From: David Miller @ 2010-05-11 6:14 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1273522735-24672-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Mon, 10 May 2010 22:17:31 +0200
> appologies for not sending this earlier in smaller batches, as mentioned
> earlier I ran into some problems with git. Following is a first netfilter
> update for 2.6.35, containing:
...
> The patches won't apply cleanly because of some conflicts resolved during
> merges, please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git master
Looks good, pulled, thanks Patrick.
Please double check that the device leak in xt_TEE pointed out by Eric
really got fixed properly in the end.
Thanks.
^ permalink raw reply
* Re: TCP-MD5 checksum failure on x86_64 SMP
From: Eric Dumazet @ 2010-05-11 6:27 UTC (permalink / raw)
To: Bijay Singh
Cc: Stephen Hemminger, David Miller, <bhaskie@gmail.com>,
<bhutchings@solarflare.com>, <netdev@vger.kernel.org>
In-Reply-To: <AAFABD0F-C66F-44C2-8BDC-FB489EA8655F@guavus.com>
Le mardi 11 mai 2010 à 04:08 +0000, Bijay Singh a écrit :
> Hi Eric,
>
> I guess that makes me the enviable one. So I am keen to test out this feature
> completely, as long as I know what to do as a next step, directions, patches.
>
MTU > 4000 is not reliable because of high order allocations on typical
NICS. I am afraid you need NIC able to deliver page fragments.
Its working here (32bit kernel) with a tg3 NIC, but I got following
message :
ifconfig eth3 mtu 9000
...
[51492.936500] 167731 total pagecache pages
[51492.936500] 0 pages in swap cache
[51492.936500] Swap cache stats: add 0, delete 0, find 0/0
[51492.936500] Free swap = 4192928kB
[51492.936500] Total swap = 4192928kB
[51492.936500] 1114110 pages RAM
[51492.936500] 885761 pages HighMem
[51492.936500] 77073 pages reserved
[51492.936500] 134483 pages shared
[51492.936500] 159131 pages non-shared
[51492.953027] tg3 0000:14:04.1: eth3: Using a smaller RX standard ring.
Only 183 out of 511 buffers were allocated successfully
$ ethtool -g eth3
Ring parameters for eth3:
Pre-set maximums:
RX: 511
RX Mini: 0
RX Jumbo: 0
TX: 511
Current hardware settings:
RX: 183
RX Mini: 0
RX Jumbo: 0
TX: 511
$ cat /proc/buddyinfo
Node 0, zone DMA 5 2 1 1 2 2 2 1 0 1 0
Node 0, zone Normal 4285 1823 248 73 9 5 0 0 0 0 0
Node 0, zone HighMem 97 199 921 583 383 261 155 117 69 41 649
I know that if I try to stress RX path, I'll get failures.
Could you explain me why you need both big MTUS and TCP-MD5 ?
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2010-05-11 7:01 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix SCTP race between connect() and ICMP unreachable, from Vlad Yasevich.
2) Micrel phy driver OOPS fix, based upon a report by Ingo Molnar.
3) Firmware loading warn_on fix from Christian Lamparter.
4) UDP logs garbage addresses on short packets. Fix from Bjørn Mork.
5) IPV6_RECVERR incorrectly handles locally generated errors, fix from
Brian Haley.
6) IPV4 multicast purges routes too quickly due to mishandling of timers.
Fix from Andreas Meissner.
7) Passive scans busted in iwlwifi, fix from Johannes Berg.
8) De-auth request handling fix in mac80211 from Reinette Chatre.
9) gianfar needs to purge cached recycled SKBs on MTU change, fix from
Sebastian Andrzej Siewior
Please pull, thanks a lot!
The following changes since commit 8777c793d6a24c7f3adf52b1b1086e9706de4589:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../tj/wq
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Andreas Meissner (1):
IPv4: unresolved multicast route cleanup
Bjørn Mork (1):
ipv4: udp: fix short packet and bad checksum logging
Brian Haley (1):
IPv6: fix IPV6_RECVERR handling of locally-generated errors
Christian Lamparter (1):
ar9170: wait for asynchronous firmware loading
David S. Miller (3):
phy: Fix initialization in micrel driver.
net: Fix FDDI and TR config checks in ipv4 arp and LLC.
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Eric Dumazet (1):
veth: Dont kfree_skb() after dev_forward_skb()
Johannes Berg (1):
iwlwifi: work around passive scan issue
Reinette Chatre (1):
mac80211: remove association work when processing deauth request
Sebastian Andrzej Siewior (1):
net/gianfar: drop recycled skbs on MTU change
Vlad Yasevich (1):
sctp: Fix a race between ICMP protocol unreachable and connect()
drivers/net/gianfar.c | 2 +-
drivers/net/phy/micrel.c | 1 +
drivers/net/veth.c | 1 -
drivers/net/wireless/ath/ar9170/usb.c | 11 ++++++++
drivers/net/wireless/ath/ar9170/usb.h | 1 +
drivers/net/wireless/iwlwifi/iwl-commands.h | 4 ++-
drivers/net/wireless/iwlwifi/iwl-scan.c | 23 ++++++++++++++----
drivers/net/wireless/iwlwifi/iwl3945-base.c | 3 +-
include/net/sctp/sm.h | 1 +
include/net/sctp/structs.h | 3 ++
net/core/dev.c | 11 ++++----
net/ipv4/arp.c | 6 ++--
net/ipv4/ipmr.c | 3 +-
net/ipv4/udp.c | 6 ++--
net/ipv6/datagram.c | 8 ++++-
net/llc/llc_sap.c | 2 +-
net/mac80211/mlme.c | 3 +-
net/sctp/input.c | 22 ++++++++++++++---
net/sctp/sm_sideeffect.c | 35 +++++++++++++++++++++++++++
net/sctp/transport.c | 2 +
20 files changed, 118 insertions(+), 30 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/9] netdev: bfin_mac: add support for IEEE 1588 PTP
From: Richard Cochran @ 2010-05-11 7:07 UTC (permalink / raw)
To: Mike Frysinger; +Cc: netdev, David S. Miller, uclinux-dist-devel, Barry Song
In-Reply-To: <1273505954-32588-1-git-send-email-vapier@gentoo.org>
On Mon, May 10, 2010 at 11:39:06AM -0400, Mike Frysinger wrote:
> diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
> index 587f93c..6a9519f 100644
> --- a/drivers/net/bfin_mac.c
> +++ b/drivers/net/bfin_mac.c
...
> +#define PTP_CLK 25000000
> +
> +static void bfin_mac_hwtstamp_init(struct net_device *netdev)
> +{
> + struct bfin_mac_local *lp = netdev_priv(netdev);
> + u64 append;
> +
> + /* Initialize hardware timer */
> + append = PTP_CLK * (1ULL << 32);
> + do_div(append, get_sclk());
> + bfin_write_EMAC_PTP_ADDEND((u32)append);
It appears that one can tune this PTP clock.
I recently posted a suggestion for a PTP clock class driver. Would you
care to take a look at that and say whether that API would also work
for the blackfin?
Thanks,
Richard
^ permalink raw reply
* Re: TCP-MD5 checksum failure on x86_64 SMP
From: Bijay Singh @ 2010-05-11 8:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Hemminger, David Miller, <bhaskie@gmail.com>,
<bhutchings@solarflare.com>, <netdev@vger.kernel.org>
In-Reply-To: <1273559267.2339.6.camel@edumazet-laptop>
I need MD5 for my BGP sessions and need the jumbo packets for the IS-IS peering. MTU of 1500 results in LSPs higher that 1500 getting dropped at the peering router.
On 11-May-2010, at 11:57 AM, Eric Dumazet wrote:
> Le mardi 11 mai 2010 à 04:08 +0000, Bijay Singh a écrit :
>> Hi Eric,
>>
>> I guess that makes me the enviable one. So I am keen to test out this feature
>
>> completely, as long as I know what to do as a next step, directions, patches.
>>
>
> MTU > 4000 is not reliable because of high order allocations on typical
> NICS. I am afraid you need NIC able to deliver page fragments.
>
> Its working here (32bit kernel) with a tg3 NIC, but I got following
> message :
>
> ifconfig eth3 mtu 9000
> ...
> [51492.936500] 167731 total pagecache pages
> [51492.936500] 0 pages in swap cache
> [51492.936500] Swap cache stats: add 0, delete 0, find 0/0
> [51492.936500] Free swap = 4192928kB
> [51492.936500] Total swap = 4192928kB
> [51492.936500] 1114110 pages RAM
> [51492.936500] 885761 pages HighMem
> [51492.936500] 77073 pages reserved
> [51492.936500] 134483 pages shared
> [51492.936500] 159131 pages non-shared
> [51492.953027] tg3 0000:14:04.1: eth3: Using a smaller RX standard ring.
> Only 183 out of 511 buffers were allocated successfully
>
> $ ethtool -g eth3
> Ring parameters for eth3:
> Pre-set maximums:
> RX: 511
> RX Mini: 0
> RX Jumbo: 0
> TX: 511
> Current hardware settings:
> RX: 183
> RX Mini: 0
> RX Jumbo: 0
> TX: 511
>
> $ cat /proc/buddyinfo
> Node 0, zone DMA 5 2 1 1 2 2 2 1 0 1 0
> Node 0, zone Normal 4285 1823 248 73 9 5 0 0 0 0 0
> Node 0, zone HighMem 97 199 921 583 383 261 155 117 69 41 649
>
> I know that if I try to stress RX path, I'll get failures.
>
> Could you explain me why you need both big MTUS and TCP-MD5 ?
>
>
>
^ permalink raw reply
* Re: [PATCH net-next 3/3] cxgb4: report GRO stats with ethtool -S
From: Dimitris Michailidis @ 2010-05-11 8:45 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <4BE8C8CD.1000200@candelatech.com>
Ben Greear wrote:
> On 05/10/2010 06:58 PM, Dimitris Michailidis wrote:
>> Signed-off-by: Dimitris Michailidis<dm@chelsio.com>
>
> One of these is on-wire packets? If so, maybe use the same
> string as Intel ixgbe uses:
>
> rx_pkts_nic # Pkts received by NIC from wire.
> rx_bytes_nic # Bytes received by NIC from wire.
> tx_pkts_nic # Pkts transmitted to wire by NIC.
> tx_bytes_nic # Bytes transmitted to wire by NIC.
The two stats I'm adding don't correspond to any of the 4 above. One is the
superpackets coming out of GRO, the other is packets merged by GRO to create
the superpackets.
>
> Thanks,
> Ben
>
>
>
>> ---
>> drivers/net/cxgb4/cxgb4_main.c | 6 ++++++
>> 1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/cxgb4/cxgb4_main.c
>> b/drivers/net/cxgb4/cxgb4_main.c
>> index 80c3fc5..90d375b 100644
>> --- a/drivers/net/cxgb4/cxgb4_main.c
>> +++ b/drivers/net/cxgb4/cxgb4_main.c
>> @@ -859,6 +859,8 @@ static char stats_strings[][ETH_GSTRING_LEN] = {
>> "RxCsumGood ",
>> "VLANextractions ",
>> "VLANinsertions ",
>> + "GROpackets ",
>> + "GROmerged ",
>> };
>>
>> static int get_sset_count(struct net_device *dev, int sset)
>> @@ -922,6 +924,8 @@ struct queue_port_stats {
>> u64 rx_csum;
>> u64 vlan_ex;
>> u64 vlan_ins;
>> + u64 gro_pkts;
>> + u64 gro_merged;
>> };
>>
>> static void collect_sge_port_stats(const struct adapter *adap,
>> @@ -938,6 +942,8 @@ static void collect_sge_port_stats(const struct
>> adapter *adap,
>> s->rx_csum += rx->stats.rx_cso;
>> s->vlan_ex += rx->stats.vlan_ex;
>> s->vlan_ins += tx->vlan_ins;
>> + s->gro_pkts += rx->stats.lro_pkts;
>> + s->gro_merged += rx->stats.lro_merged;
>> }
>> }
>>
>
>
^ permalink raw reply
* Re: [PATCH 72/84] netfilter: xtables: inclusion of xt_TEE
From: Patrick McHardy @ 2010-05-11 11:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <1273524779.2590.236.camel@edumazet-laptop>
Eric Dumazet wrote:
> Le lundi 10 mai 2010 à 22:18 +0200, kaber@trash.net a écrit :
>> From: Jan Engelhardt <jengelh@medozas.de>
>>
>> xt_TEE can be used to clone and reroute a packet. This can for
>> example be used to copy traffic at a router for logging purposes
>> to another dedicated machine.
>>
>> References: http://www.gossamer-threads.com/lists/iptables/devel/68781
>> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
>> Signed-off-by: Patrick McHardy <kaber@trash.net>
>> ---
>
>> +static bool tee_tg_route_oif(struct flowi *f, struct net *net,
>> + const struct xt_tee_tginfo *info)
>> +{
>> + const struct net_device *dev;
>> +
>> + if (*info->oif != '\0')
>> + return true;
>> + dev = dev_get_by_name(net, info->oif);
>> + if (dev == NULL)
>> + return false;
>> + f->oif = dev->ifindex;
>> + return true;
>> +}
>> +
>
> This leaks a refcount on device.
>
> But I see patch 76/84 replaces the whole thing, so this is probably
> harmless.
Correct, that patch replaces the per-packet lookup and uses
netdevice notifiers to store the ifindex of the output device,
without keeping a reference at all.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] virtif: initial interface extensions
From: Arnd Bergmann @ 2010-05-11 12:25 UTC (permalink / raw)
To: Stefan Berger; +Cc: netdev, Scott Feldman
In-Reply-To: <OFFE8F5F70.5C07C656-ON8525771F.00787A71-8525771F.007FCDFC@us.ibm.com>
On Tuesday 11 May 2010, Stefan Berger wrote:
> Arnd Bergmann <arnd@arndb.de> wrote on 05/10/2010 05:46:37 PM:
>
> > Stefan, can you just define the XML in a way that matches the netlink
> > definition? What you need is something like
> >
> > 1. VF number (optional, signifies that 2/3 are done in firmware)
>
> Shouldn't we be able to query that number via netlink starting with the
> macvtap device and the following the trail to the root and trying to find
> a VF number on the way?
No. If we have a macvtap device, there is no VF number. The VF number
should be known to libvirt in those cases where instead of creating a
macvtap device, it assigns a VF of an SR-IOV adapter to the guest.
> > 2. Lower-level protocol
> > 2.1. CDCP
> > 2.1.1 SVID
> > 2.1.2 SCID
>
> Will the later on be qeueryable via netlink as well but not today???
> Vivek tells me svid is vlan, so that could be found out from the kernel.
>
> So if we want to only support 1 and 2 for now, I'd rather skip them for
> now.
svid is almost vlan (hence S-VLAN), but slightly different and is not
currently supported by the kernel. Again, if the implementation is done in
firmware, libvirt needs to set the same S-VLAN ID when setting up the
VF and when associating it to the switch.
When it's done in software, we need to create the device (or have
it created in advance), so you either know it or can query it as
you describe.
You don't need to support it yet in libvirt, but the definition should
be done in a way that leaves the option open to add it later.
> > 2.2.2 ...
> > 3. VDP
> > 3.1 VSI type/version/provider
>
> as proposed on libvirt mailing list
>
> > 3.2 UUID
>
> we have a couple of UUIDs, which one?
This is a UUID that describes the VSI to the switch. It needs to be
unique in the migration domain. For a guest that has multiple
macvtap interfaces, you either need to have a single UUID and
put all MAC/VLAN pairs into the same netlink message with this
UUID, or have one UUID per device.
> > 3.3 MAC/VLAN
>
> MAC: available from libvirt
> VLAN: can be found out by querying for every interface for VLAN ID while
> following the path towards the root device.
Yes, in case of macvtap.
Arnd
^ permalink raw reply
* Re: [PATCH] virtif: initial interface extensions
From: Arnd Bergmann @ 2010-05-11 12:59 UTC (permalink / raw)
To: Scott Feldman; +Cc: Stefan Berger, netdev, chrisw, davem
In-Reply-To: <C80DF1EC.2FFE0%scofeldm@cisco.com>
On Tuesday 11 May 2010, Scott Feldman wrote:
> On 5/10/10 2:46 PM, "Arnd Bergmann" <arnd@arndb.de> wrote:
>
> > Stefan, can you just define the XML in a way that matches the netlink
> > definition? What you need is something like
> >
> > 1. VF number (optional, signifies that 2/3 are done in firmware)
> > 2. Lower-level protocol
> > 2.1. CDCP
> > 2.1.1 SVID
> > 2.1.2 SCID
> > 2.2. enic
> > 2.2.1 port profile name
> > 2.2.2 ...
> > 3. VDP
> > 3.1 VSI type/version/provider
> > 3.2 UUID
> > 3.3 MAC/VLAN
> >
> > You need to have 2. or 3. or both, and 2.1/2.2 are mutually exclusive.
>
> I'm don't think this is going in the right direction. We're talking a
> pretty simple concept of a port-profile used to configure the virtual port
> backing a VM i/f to something that's trying to munge disjoint protocols
> based on pre-standard work into a single API. It's forcing all those
> pre-standard protocol details into the API, into the XML, and into the mgmt
> software (libvirt), and into the admin's lap.
No. I agree that the port-profile concept is simple and that the complexity
comes from trying to merge the Linux interface with what we do for VDP.
It would be much more sensible IMHO to just unify port-profiles and CDCP
in the kernel interface, because they are conceptually more similar and
both rather simple (note that there is no S-VLAN implementation in Linux,
so CDCP is not there yet either).
If we layer VDP on top of the two and do it always in user space (LLDPAD
with lldptool), things are much simpler on the interface side.
The focus of VDP is to manage migration, which is something that
enic doesn't do (or doesn't need to do) and most of the complexity
in there comes from this.
> I want the API to pass a port-profile name plus other information associated
> with the VM i/f to some mgmt object which can setup the virtual port backing
> the VM i/f. (And unset it). Using netlink for API let's that object be in
> user- or kernel-space software, hardware or firmware. How the object sets
> up the virtual port based on the passed port-profile is beyond the scope of
> the API.
>
> My last port-profile patch is this API. It gives us this:
>
> 1) single netlink msg for kernel- and user-space
Except for the VF argument, which is kernel- only, and it doesn't work
if user space needs additional information that only the firmware has
in your case (something like a virtual channel ID).
> 2) single parameter set from sender's perspective (libvirt)
> 3) single XML representation of parameters
> 4) single code path in kernel and libvirt
> 5) (potential) cross-vendor-switch VM migration
You cannot do live migration between Cisco switches and those implementing
802.1Qbg, because of the differences between port profiles and VSI types,
e.g. how they handle VLANs or handover during migration.
Migration between 802.1Qbg capable switches is covered by the standard.
> 6) admin-friendly port-profile names
> 7) allows pre-standard (802.1Qbg/bh) details to change
> without bogging down the API
We're basically nailing down the API right here. As soon as this is
supported in Linux, it will be the standard, so the details won't
be able to change any more.
> What I proposed on the libvirt list is to maintain a mapping database from
> port-profile to vendor-specific or protocol-specific parameters. Using VDP
> as an example, a port-profile would resolve the VDP tuple:
>
> port-profile: "joes-garage" ---> VSI Manager ID: 15
> VSI Type ID: 12345
> VSI Type ID Ver: 1
> other VSI settings (preassociate)
I agree that the port profile name matches the VSI manager/type/version ID
to a large degree and that it would be nice to unify these, but I don't think
there is a point given all the other differences.
There is no way around the preassociate/associate/disassociate messages
being part of the API, because otherwise you cannot do seamless migration
across multiple switches.
Also, the primary key on VDP is the VSI UUID, which needs to be the same
on the target host after migration, while in your case the switch never
identifies the guest itself, only the port profile.
If I have understood you correctly, the primary key identifying a port
on enic is something that is only visible to the switch and nic firmware,
but never to software, so you identify the guest by its VF number on the
user API.
Arnd
^ permalink raw reply
* get beyond 1Gbps with pktgen on 10Gb nic?
From: Jon Zhou @ 2010-05-11 13:13 UTC (permalink / raw)
To: netdev@vger.kernel.org
hi there:
anyone can get beyond 1Gbps with pktgen or other SW traffic generator with 10Gb nic(intel 82599 or BCM 57711)?
found that some one had met similar situation with broadcom 10G nic but no solution yet
thanks
jon
^ permalink raw reply
* Re: get beyond 1Gbps with pktgen on 10Gb nic?
From: Ben Hutchings @ 2010-05-11 13:35 UTC (permalink / raw)
To: Jon Zhou; +Cc: netdev@vger.kernel.org
In-Reply-To: <4A6A2125329CFD4D8CC40C9E8ABCAB9F2497D752C7@MILEXCH2.ds.jdsu.net>
On Tue, 2010-05-11 at 06:13 -0700, Jon Zhou wrote:
> hi there:
>
> anyone can get beyond 1Gbps with pktgen or other SW traffic generator with 10Gb nic(intel 82599 or BCM 57711)?
> found that some one had met similar situation with broadcom 10G nic but no solution yet
I don't know about those specific controllers, but you should be able to
achieve close to 10G line rate with netperf's TCP_STREAM on any recent
PC server. UDP throughput tends to be poorer as there is less support
for offloading segmentation and reassembly. Performance may also be
constrained by PCI Express bandwidth (you need a real 8-lane slot) and
memory bandwidth (a single memory bank may not be enough).
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
* [PATCH 0/6] ipv6: ip6mr: support multiple independant multicast routing instances
From: kaber @ 2010-05-11 14:02 UTC (permalink / raw)
To: davem; +Cc: netdev
The following patches add support for multiple independant IPv6 multicast
routing instances. This can be useful to seperate traffic when building
a multicast router that is serving multiple independant networks.
The patchset is pretty much a straight forward port from IPv4 with no
significant differences.
The patchset consists of the following parts:
- Patch 01-04 contain some preparatory work and cleanup for supporting
multiple multicast routing instances.
- Patch 05 contains the actual changes to support multiple multicast
routing instances.
- Patch 06 adds support for dumping multicast routing routes from all
tables over netlink.
These patches have been tested using pim6sd and mrd6.
Please apply or pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/kaber/ipmr-2.6.git master
Thanks!
^ 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