* Re: [RFC PATCH net-next 1/1] net: Support for switch port configuration
From: Roopa Prabhu @ 2014-12-11 16:37 UTC (permalink / raw)
To: Jiri Pirko
Cc: Varlese, Marco, John Fastabend, netdev@vger.kernel.org,
stephen@networkplumber.org, Fastabend, John R, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <20141211110115.GA1979@nanopsycho.lan>
On 12/11/14, 3:01 AM, Jiri Pirko wrote:
> Thu, Dec 11, 2014 at 10:59:42AM CET, marco.varlese@intel.com wrote:
>>> -----Original Message-----
>>> From: John Fastabend [mailto:john.fastabend@gmail.com]
>>> Sent: Wednesday, December 10, 2014 5:04 PM
>>> To: Jiri Pirko
>>> Cc: Varlese, Marco; netdev@vger.kernel.org;
>>> stephen@networkplumber.org; Fastabend, John R;
>>> roopa@cumulusnetworks.com; sfeldma@gmail.com; linux-
>>> kernel@vger.kernel.org
>>> Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port
>>> configuration
>>>
>>> On 12/10/2014 08:50 AM, Jiri Pirko wrote:
>>>> Wed, Dec 10, 2014 at 05:23:40PM CET, marco.varlese@intel.com wrote:
>>>>> From: Marco Varlese <marco.varlese@intel.com>
>>>>>
>>>>> Switch hardware offers a list of attributes that are configurable on
>>>>> a per port basis.
>>>>> This patch provides a mechanism to configure switch ports by adding
>>>>> an NDO for setting specific values to specific attributes.
>>>>> There will be a separate patch that extends iproute2 to call the new
>>>>> NDO.
>>>>
>>>> What are these attributes? Can you give some examples. I'm asking
>>>> because there is a plan to pass generic attributes to switch ports
>>>> replacing current specific ndo_switch_port_stp_update. In this case,
>>>> bridge is setting that attribute.
>>>>
>>>> Is there need to set something directly from userspace or does it make
>>>> rather sense to use involved bridge/ovs/bond ? I think that both will
>>>> be needed.
>>> +1
>>>
>>> I think for many attributes it would be best to have both. The in kernel callers
>>> and netlink userspace can use the same driver ndo_ops.
>>>
>>> But then we don't _require_ any specific bridge/ovs/etc module. And we
>>> may have some attributes that are not specific to any existing software
>>> module. I'm guessing Marco has some examples of these.
>>>
>>> [...]
>>>
>>>
>>> --
>>> John Fastabend Intel Corporation
>> We do have a need to configure the attributes directly from user-space and I have identified the tool to do that in iproute2.
>>
>> An example of attributes are:
>> * enabling/disabling of learning of source addresses on a given port (you can imagine the attribute called LEARNING for example);
>> * internal loopback control (i.e. LOOPBACK) which will control how the flow of traffic behaves from the switch fabric towards an egress port;
>> * flooding for broadcast/multicast/unicast type of packets (i.e. BFLOODING, MFLOODING, UFLOODING);
>>
>> Some attributes would be of the type enabled/disabled while other will allow specific values to allow the user to configure different behaviours of that feature on that particular port on that platform.
>>
>> One thing to mention - as John stated as well - there might be some attributes that are not specific to any software module but rather have to do with the actual hardware/platform to configure.
>>
>> I hope this clarifies some points.
> It does. Makes sense. We need to expose this attr set/get for both
> in-kernel and userspace use cases.
>
> Please adjust you patch for this. Also, as a second patch, it would be
> great if you can convert ndo_switch_port_stp_update to this new ndo.
Why are we exposing generic switch attribute get/set from userspace ?.
We already have specific attributes for learning/flooding which can be
extended further.
And for in kernel api....i had a sample patch in my RFC series (Which i
was going to resubmit, until it was decided that we will use existing
api around ndo_bridge_setlink/ndo_bridge_getlink):
http://www.spinics.net/lists/netdev/msg305473.html
Thanks,
Roopa
^ permalink raw reply
* Re: [PATCH iproute2] ip: Simplify executing ip cmd within namespace
From: Jiri Benc @ 2014-12-11 16:09 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1418252195-2612-1-git-send-email-vadim4j@gmail.com>
On Thu, 11 Dec 2014 00:56:35 +0200, Vadim Kochan wrote:
> From: Vadim Kochan <vadim4j@gmail.com>
>
> Added new '-ns' option to simplify executing following cmd:
>
> ip netns exec NETNS ip OPTIONS COMMAND OBJECT
>
> to
>
> ip -ns NETNS OPTIONS COMMAND OBJECT
>
> e.g.:
>
> ip -ns vnet0 link add br0 type bridge
This is great! It's a thing that has been bothering me for long time
but never got high enough on my todo list. Thanks for working on this.
However,
> --- a/ip/ip.c
> +++ b/ip/ip.c
> @@ -262,6 +262,12 @@ int main(int argc, char **argv)
> rcvbuf = size;
> } else if (matches(opt, "-help") == 0) {
> usage();
> + } else if (matches(opt, "-ns") == 0) {
> + argc--;
> + argv++;
> + argv[0] = argv[1];
> + argv[1] = basename;
> + return netns_exec(argc, argv);
I very much dislike this. There's no reason to exec another ip binary.
The main reason I wanted the -n (or whatever) option was to speed up
execution of test scripts in environments with hundreds of interfaces
in different net namespaces.
Please just change to the specified netns and continue with interpreting
of the rest of the command line, there's absolutely no reason for doing
the exec.
Thanks,
Jiri
--
Jiri Benc
^ permalink raw reply
* [PATCH net v9 4/7] cxgb4i: additional types of negative advice
From: Karen Xie @ 2014-12-11 15:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
From: Karen Xie <kxie@chelsio.com>
Treat both CPL_ERR_KEEPALV_NEG_ADVICE and CPL_ERR_PERSIST_NEG_ADVICE as
negative advice.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 5f31eb7..2880f200 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -846,6 +846,13 @@ static void csk_act_open_retry_timer(unsigned long data)
}
+static inline bool is_neg_adv(unsigned int status)
+{
+ return status == CPL_ERR_RTX_NEG_ADVICE ||
+ status == CPL_ERR_KEEPALV_NEG_ADVICE ||
+ status == CPL_ERR_PERSIST_NEG_ADVICE;
+}
+
static void do_act_open_rpl(struct cxgbi_device *cdev, struct sk_buff *skb)
{
struct cxgbi_sock *csk;
@@ -867,7 +874,7 @@ static void do_act_open_rpl(struct cxgbi_device *cdev, struct sk_buff *skb)
"csk 0x%p,%u,0x%lx. ", (&csk->saddr), (&csk->daddr),
atid, tid, status, csk, csk->state, csk->flags);
- if (status == CPL_ERR_RTX_NEG_ADVICE)
+ if (is_neg_adv(status))
goto rel_skb;
module_put(THIS_MODULE);
@@ -973,8 +980,7 @@ static void do_abort_req_rss(struct cxgbi_device *cdev, struct sk_buff *skb)
(&csk->saddr), (&csk->daddr),
csk, csk->state, csk->flags, csk->tid, req->status);
- if (req->status == CPL_ERR_RTX_NEG_ADVICE ||
- req->status == CPL_ERR_PERSIST_NEG_ADVICE)
+ if (is_neg_adv(req->status))
goto rel_skb;
cxgbi_sock_get(csk);
^ permalink raw reply related
* [PATCH net v9 2/7] cxgb4i: fix credit check for tx_data_wr
From: Karen Xie @ 2014-12-11 15:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
From: Karen Xie <kxie@chelsio.com>
make sure any tx credit related checking is done before adding the wr header.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index f119a67..abee611 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -547,10 +547,11 @@ static inline void make_tx_data_wr(struct cxgbi_sock *csk, struct sk_buff *skb,
struct fw_ofld_tx_data_wr *req;
unsigned int submode = cxgbi_skcb_ulp_mode(skb) & 3;
unsigned int wr_ulp_mode = 0;
+ bool imm = is_ofld_imm(skb);
req = (struct fw_ofld_tx_data_wr *)__skb_push(skb, sizeof(*req));
- if (is_ofld_imm(skb)) {
+ if (imm) {
req->op_to_immdlen = htonl(FW_WR_OP(FW_OFLD_TX_DATA_WR) |
FW_WR_COMPL(1) |
FW_WR_IMMDLEN(dlen));
^ permalink raw reply related
* RE: [PATCH net v8 1/7] cxgb4i: fix tx immediate data credit check
From: Karen Xie @ 2014-12-11 15:26 UTC (permalink / raw)
To: David Miller
Cc: linux-scsi@vger.kernel.org, netdev@vger.kernel.org, Hariprasad S,
Anish Bhatt, hch@infradead.org,
James.Bottomley@HansenPartnership.com, michaelc@cs.wisc.edu
In-Reply-To: <20141210.225445.458745535803327140.davem@davemloft.net>
From: David Miller [mailto:davem@davemloft.net]
Sent: Wednesday, December 10, 2014 7:55 PM
> Please text format your commit messages to 80 characters or less per line.
>
> People are going to read your commits using text tools, not necessarily GUI
> tools which will auto-format your commit message.
>
> I know this seems like we are being difficult, but you are making many
> fundamental mistakes in your efforts to merge in these changes.
Submitted v9 with reformatted commit messages. Thanks for your patience.
^ permalink raw reply
* [PATCH net v9 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware
From: Karen Xie @ 2014-12-11 15:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
From: Karen Xie <kxie@chelsio.com>
Programs the firmware of the maximum outgoing iscsi pdu length per connection.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 69 +++++++++++++++++++++++++++---------
1 files changed, 51 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 3409756..743a350 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -529,6 +529,7 @@ enum fw_flowc_mnem {
FW_FLOWC_MNEM_RCVNXT,
FW_FLOWC_MNEM_SNDBUF,
FW_FLOWC_MNEM_MSS,
+ FW_FLOWC_MNEM_TXDATAPLEN_MAX,
};
struct fw_flowc_mnemval {
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index abee611..5f31eb7 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -75,6 +75,7 @@ typedef void (*cxgb4i_cplhandler_func)(struct cxgbi_device *, struct sk_buff *);
static void *t4_uld_add(const struct cxgb4_lld_info *);
static int t4_uld_rx_handler(void *, const __be64 *, const struct pkt_gl *);
static int t4_uld_state_change(void *, enum cxgb4_state state);
+static inline int send_tx_flowc_wr(struct cxgbi_sock *);
static const struct cxgb4_uld_info cxgb4i_uld_info = {
.name = DRV_MODULE_NAME,
@@ -391,6 +392,12 @@ static void send_abort_req(struct cxgbi_sock *csk)
if (unlikely(csk->state == CTP_ABORTING) || !skb || !csk->cdev)
return;
+
+ if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
+ send_tx_flowc_wr(csk);
+ cxgbi_sock_set_flag(csk, CTPF_TX_DATA_SENT);
+ }
+
cxgbi_sock_set_state(csk, CTP_ABORTING);
cxgbi_sock_set_flag(csk, CTPF_ABORT_RPL_PENDING);
cxgbi_sock_purge_write_queue(csk);
@@ -493,20 +500,40 @@ static inline unsigned int calc_tx_flits_ofld(const struct sk_buff *skb)
return flits + sgl_len(cnt);
}
-static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
+#define FLOWC_WR_NPARAMS_MIN 9
+static inline int tx_flowc_wr_credits(int *nparamsp, int *flowclenp)
+{
+ int nparams, flowclen16, flowclen;
+
+ nparams = FLOWC_WR_NPARAMS_MIN;
+ flowclen = offsetof(struct fw_flowc_wr, mnemval[nparams]);
+ flowclen16 = DIV_ROUND_UP(flowclen, 16);
+ flowclen = flowclen16 * 16;
+ /*
+ * Return the number of 16-byte credits used by the FlowC request.
+ * Pass back the nparams and actual FlowC length if requested.
+ */
+ if (nparamsp)
+ *nparamsp = nparams;
+ if (flowclenp)
+ *flowclenp = flowclen;
+
+ return flowclen16;
+}
+
+static inline int send_tx_flowc_wr(struct cxgbi_sock *csk)
{
struct sk_buff *skb;
struct fw_flowc_wr *flowc;
- int flowclen, i;
+ int nparams, flowclen16, flowclen;
- flowclen = 80;
+ flowclen16 = tx_flowc_wr_credits(&nparams, &flowclen);
skb = alloc_wr(flowclen, 0, GFP_ATOMIC);
flowc = (struct fw_flowc_wr *)skb->head;
flowc->op_to_nparams =
- htonl(FW_WR_OP(FW_FLOWC_WR) | FW_FLOWC_WR_NPARAMS(8));
+ htonl(FW_WR_OP(FW_FLOWC_WR) | FW_FLOWC_WR_NPARAMS(nparams));
flowc->flowid_len16 =
- htonl(FW_WR_LEN16(DIV_ROUND_UP(72, 16)) |
- FW_WR_FLOWID(csk->tid));
+ htonl(FW_WR_LEN16(flowclen16) | FW_WR_FLOWID(csk->tid));
flowc->mnemval[0].mnemonic = FW_FLOWC_MNEM_PFNVFN;
flowc->mnemval[0].val = htonl(csk->cdev->pfvf);
flowc->mnemval[1].mnemonic = FW_FLOWC_MNEM_CH;
@@ -525,11 +552,9 @@ static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
flowc->mnemval[7].val = htonl(csk->advmss);
flowc->mnemval[8].mnemonic = 0;
flowc->mnemval[8].val = 0;
- for (i = 0; i < 9; i++) {
- flowc->mnemval[i].r4[0] = 0;
- flowc->mnemval[i].r4[1] = 0;
- flowc->mnemval[i].r4[2] = 0;
- }
+ flowc->mnemval[8].mnemonic = FW_FLOWC_MNEM_TXDATAPLEN_MAX;
+ flowc->mnemval[8].val = 16384;
+
set_queue(skb, CPL_PRIORITY_DATA, csk);
log_debug(1 << CXGBI_DBG_TOE | 1 << CXGBI_DBG_SOCK,
@@ -539,6 +564,8 @@ static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
csk->advmss);
cxgb4_ofld_send(csk->cdev->ports[csk->port_id], skb);
+
+ return flowclen16;
}
static inline void make_tx_data_wr(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -599,6 +626,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
int dlen = skb->len;
int len = skb->len;
unsigned int credits_needed;
+ int flowclen16 = 0;
skb_reset_transport_header(skb);
if (is_ofld_imm(skb))
@@ -613,6 +641,17 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
sizeof(struct fw_ofld_tx_data_wr),
16);
+ /*
+ * Assumes the initial credits is large enough to support
+ * fw_flowc_wr plus largest possible first payload
+ */
+ if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
+ flowclen16 = send_tx_flowc_wr(csk);
+ csk->wr_cred -= flowclen16;
+ csk->wr_una_cred += flowclen16;
+ cxgbi_sock_set_flag(csk, CTPF_TX_DATA_SENT);
+ }
+
if (csk->wr_cred < credits_needed) {
log_debug(1 << CXGBI_DBG_PDU_TX,
"csk 0x%p, skb %u/%u, wr %d < %u.\n",
@@ -622,7 +661,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
}
__skb_unlink(skb, &csk->write_queue);
set_queue(skb, CPL_PRIORITY_DATA, csk);
- skb->csum = credits_needed;
+ skb->csum = credits_needed + flowclen16;
csk->wr_cred -= credits_needed;
csk->wr_una_cred += credits_needed;
cxgbi_sock_enqueue_wr(csk, skb);
@@ -633,12 +672,6 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
csk->wr_cred, csk->wr_una_cred);
if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR))) {
- if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
- send_tx_flowc_wr(csk);
- skb->csum += 5;
- csk->wr_cred -= 5;
- csk->wr_una_cred += 5;
- }
len += cxgbi_ulp_extra_len(cxgbi_skcb_ulp_mode(skb));
make_tx_data_wr(csk, skb, dlen, len, credits_needed,
req_completion);
^ permalink raw reply related
* [PATCH net v9 1/7] cxgb4i: fix tx immediate data credit check
From: Karen Xie @ 2014-12-11 15:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
From: Karen Xie <kxie@chelsio.com>
Only data skbs need the wr header added while control skbs do not. Make sure
they are treated differently.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 22 +++++++++++++++-------
drivers/scsi/cxgbi/libcxgbi.h | 4 ++--
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 1508125..f119a67 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -171,10 +171,14 @@ static int push_tx_frames(struct cxgbi_sock *, int);
* Returns true if a packet can be sent as an offload WR with immediate
* data. We currently use the same limit as for Ethernet packets.
*/
-static inline int is_ofld_imm(const struct sk_buff *skb)
+static inline bool is_ofld_imm(const struct sk_buff *skb)
{
- return skb->len <= (MAX_IMM_TX_PKT_LEN -
- sizeof(struct fw_ofld_tx_data_wr));
+ int len = skb->len;
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ len += sizeof(struct fw_ofld_tx_data_wr);
+
+ return len <= MAX_IMM_TX_PKT_LEN;
}
static void send_act_open_req(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -597,11 +601,15 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
skb_reset_transport_header(skb);
if (is_ofld_imm(skb))
- credits_needed = DIV_ROUND_UP(dlen +
- sizeof(struct fw_ofld_tx_data_wr), 16);
+ credits_needed = DIV_ROUND_UP(dlen, 16);
else
- credits_needed = DIV_ROUND_UP(8*calc_tx_flits_ofld(skb)
- + sizeof(struct fw_ofld_tx_data_wr),
+ credits_needed = DIV_ROUND_UP(
+ 8 * calc_tx_flits_ofld(skb),
+ 16);
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ credits_needed += DIV_ROUND_UP(
+ sizeof(struct fw_ofld_tx_data_wr),
16);
if (csk->wr_cred < credits_needed) {
diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h
index 2c7cb1c..aba1af7 100644
--- a/drivers/scsi/cxgbi/libcxgbi.h
+++ b/drivers/scsi/cxgbi/libcxgbi.h
@@ -317,8 +317,8 @@ static inline void cxgbi_skcb_clear_flag(struct sk_buff *skb,
__clear_bit(flag, &(cxgbi_skcb_flags(skb)));
}
-static inline int cxgbi_skcb_test_flag(struct sk_buff *skb,
- enum cxgbi_skcb_flags flag)
+static inline int cxgbi_skcb_test_flag(const struct sk_buff *skb,
+ enum cxgbi_skcb_flags flag)
{
return test_bit(flag, &(cxgbi_skcb_flags(skb)));
}
^ permalink raw reply related
* [PATCH net v9 7/7] libcxgbi: fix freeing skb prematurely
From: Karen Xie @ 2014-12-11 15:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
From: Karen Xie <kxie@chelsio.com>
With debug turned on the debug print would access the skb after it is freed.
Fix it to free the skb after the debug print.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/libcxgbi.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index 7da59c3..eb58afc 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -2294,10 +2294,12 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task)
return err;
}
- kfree_skb(skb);
log_debug(1 << CXGBI_DBG_ISCSI | 1 << CXGBI_DBG_PDU_TX,
"itt 0x%x, skb 0x%p, len %u/%u, xmit err %d.\n",
task->itt, skb, skb->len, skb->data_len, err);
+
+ kfree_skb(skb);
+
iscsi_conn_printk(KERN_ERR, task->conn, "xmit err %d.\n", err);
iscsi_conn_failure(task->conn, ISCSI_ERR_XMIT_FAILED);
return err;
^ permalink raw reply related
* [PATCH net v9 6/7] cxgb4i: use set_wr_txq() to set tx queues
From: Karen Xie @ 2014-12-11 15:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
From: Karen Xie <kxie@chelsio.com>
use cxgb4's set_wr_txq() for setting of the tx queue for a outgoing packet.
Remove the similar function in cxgb4i.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 16 +++++-----------
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index dff7345..6aa50fc 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -157,12 +157,6 @@ static struct scsi_transport_template *cxgb4i_stt;
#define RCV_BUFSIZ_MASK 0x3FFU
#define MAX_IMM_TX_PKT_LEN 128
-static inline void set_queue(struct sk_buff *skb, unsigned int queue,
- const struct cxgbi_sock *csk)
-{
- skb->queue_mapping = queue;
-}
-
static int push_tx_frames(struct cxgbi_sock *, int);
/*
@@ -404,7 +398,7 @@ static void send_abort_req(struct cxgbi_sock *csk)
csk->cpl_abort_req = NULL;
req = (struct cpl_abort_req *)skb->head;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
req->cmd = CPL_ABORT_SEND_RST;
t4_set_arp_err_handler(skb, csk, abort_arp_failure);
INIT_TP_WR(req, csk->tid);
@@ -430,7 +424,7 @@ static void send_abort_rpl(struct cxgbi_sock *csk, int rst_status)
csk, csk->state, csk->flags, csk->tid, rst_status);
csk->cpl_abort_rpl = NULL;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
INIT_TP_WR(rpl, csk->tid);
OPCODE_TID(rpl) = cpu_to_be32(MK_OPCODE_TID(CPL_ABORT_RPL, csk->tid));
rpl->cmd = rst_status;
@@ -555,7 +549,7 @@ static inline int send_tx_flowc_wr(struct cxgbi_sock *csk)
flowc->mnemval[8].mnemonic = FW_FLOWC_MNEM_TXDATAPLEN_MAX;
flowc->mnemval[8].val = 16384;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
log_debug(1 << CXGBI_DBG_TOE | 1 << CXGBI_DBG_SOCK,
"csk 0x%p, tid 0x%x, %u,%u,%u,%u,%u,%u,%u.\n",
@@ -660,7 +654,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int req_completion)
break;
}
__skb_unlink(skb, &csk->write_queue);
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
skb->csum = credits_needed + flowclen16;
csk->wr_cred -= credits_needed;
csk->wr_una_cred += credits_needed;
@@ -1552,7 +1546,7 @@ static int ddp_ppod_write_idata(struct cxgbi_device *cdev, unsigned int port_id,
return -ENOMEM;
}
req = (struct ulp_mem_io *)skb->head;
- set_queue(skb, CPL_PRIORITY_CONTROL, NULL);
+ set_wr_txq(skb, CPL_PRIORITY_CONTROL, 0);
ulp_mem_io_set_hdr(lldi, req, wr_len, dlen, pm_addr);
idata = (struct ulptx_idata *)(req + 1);
^ permalink raw reply related
* [PATCH net v9 5/7] cxgb4i: handle non-pdu-aligned rx data
From: Karen Xie @ 2014-12-11 15:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
From: Karen Xie <kxie@chelsio.com>
Abort the connection upon receiving of cpl_rx_data, which means the pdu cannot
be recovered from the tcp stream. This generally is due to pdu header
corruption.
Signed-off-by: Karen Xie <kxie@chelsio.com>
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 2880f200..dff7345 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -1034,6 +1034,27 @@ rel_skb:
__kfree_skb(skb);
}
+static void do_rx_data(struct cxgbi_device *cdev, struct sk_buff *skb)
+{
+ struct cxgbi_sock *csk;
+ struct cpl_rx_data *cpl = (struct cpl_rx_data *)skb->data;
+ unsigned int tid = GET_TID(cpl);
+ struct cxgb4_lld_info *lldi = cxgbi_cdev_priv(cdev);
+ struct tid_info *t = lldi->tids;
+
+ csk = lookup_tid(t, tid);
+ if (!csk) {
+ pr_err("can't find connection for tid %u.\n", tid);
+ } else {
+ /* not expecting this, reset the connection. */
+ pr_err("csk 0x%p, tid %u, rcv cpl_rx_data.\n", csk, tid);
+ spin_lock_bh(&csk->lock);
+ send_abort_req(csk);
+ spin_unlock_bh(&csk->lock);
+ }
+ __kfree_skb(skb);
+}
+
static void do_rx_iscsi_hdr(struct cxgbi_device *cdev, struct sk_buff *skb)
{
struct cxgbi_sock *csk;
@@ -1453,6 +1474,7 @@ cxgb4i_cplhandler_func cxgb4i_cplhandlers[NUM_CPL_CMDS] = {
[CPL_SET_TCB_RPL] = do_set_tcb_rpl,
[CPL_RX_DATA_DDP] = do_rx_data_ddp,
[CPL_RX_ISCSI_DDP] = do_rx_data_ddp,
+ [CPL_RX_DATA] = do_rx_data,
};
int cxgb4i_ofld_init(struct cxgbi_device *cdev)
^ permalink raw reply related
* [PATCH net v9 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i
From: Karen Xie @ 2014-12-11 15:25 UTC (permalink / raw)
To: linux-scsi, netdev
Cc: kxie, hariprasad, anish, hch, James.Bottomley, michaelc, davem
This patch set fixes cxgb4i's tx credit calculation and adds handling of
additional rx message and negative advice types. It also removes the duplicate
code in cxgb4i to set the outgoing queues of a packet.
Karen Xie (7):
cxgb4i: fix tx immediate data credit check
cxgb4i: fix credit check for tx_data_wr
cxgb4/cxgb4i: set max. outgoing pdu length in the f/w
cxgb4i: add more types of negative advice
cxgb4i: handle non pdu-aligned rx data
cxgb4i: use cxgb4's set_wr_txq() for setting outgoing queues
libcxgbi: fix the debug print accessing skb after it is freed
Sending to net as the fixes are mostly in the network area and it touches
cxgb4's header file (t4fw_api.h).
v2 corrects the "CHECK"s flagged by checkpatch.pl --strict.
v3 splits the 3rd patch from v2 to two separate patches. Adds detailed commit
messages and makes subject more concise. Patch 3/6 also changes the return
value of is_neg_adv() from int to bool.
v4 -- please ignore.
v5 splits the 1st patch from v3 to two separate patches and reduces code
duplication in make_tx_data_wr().
v6 removed the code style cleanup in the 2nd patch. The style update will be
addressed in a separate patch.
v7 updates the 7th patch with more detailed commit message.
v8 removes the duplicate subject lines from the message bodies.
v9 reformatted the commit messages to be max. 80 characters per line.
^ permalink raw reply
* Re: [PATCH iproute2 v2] ip: Simplify executing ip cmd within network ns
From: vadim4j @ 2014-12-11 14:34 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Vadim Kochan, netdev
In-Reply-To: <20141211142131.GC1912@nanopsycho.orion>
On Thu, Dec 11, 2014 at 03:21:31PM +0100, Jiri Pirko wrote:
> Thu, Dec 11, 2014 at 02:38:23PM CET, vadim4j@gmail.com wrote:
> >From: Vadim Kochan <vadim4j@gmail.com>
> >
> >Added new '-netns' option to simplify executing following cmd:
> >
> > ip netns exec NETNS ip OPTIONS COMMAND OBJECT
> >
> > to
> >
> > ip -n[etns] NETNS OPTIONS COMMAND OBJECT
> >
> >e.g.:
> >
> > ip -net vnet0 link add br0 type bridge
> > ip -n vnet0 link
> >
> >Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> >---
> >Changes v1 -> v2
> > use -n[etns] option name: suggested by Nicolas Dichtel
> > changed man ip.8 page
> >
> > ip/ip.c | 6 ++++++
> > ip/ip_common.h | 1 +
> > ip/ipnetns.c | 2 +-
> > man/man8/ip.8 | 24 +++++++++++++++++++++++-
> > 4 files changed, 31 insertions(+), 2 deletions(-)
> >
> >diff --git a/ip/ip.c b/ip/ip.c
> >index 5f759d5..f3c2cdb 100644
> >--- a/ip/ip.c
> >+++ b/ip/ip.c
> >@@ -262,6 +262,12 @@ int main(int argc, char **argv)
> > rcvbuf = size;
> > } else if (matches(opt, "-help") == 0) {
> > usage();
> >+ } else if (matches(opt, "-netns") == 0) {
> >+ argc--;
> >+ argv++;
> >+ argv[0] = argv[1];
> >+ argv[1] = basename;
> >+ return netns_exec(argc, argv);
>
Hi,
>
> Can't the same functionality be done in the same ip process, meaning
> without execvp ip again? It would seem clearer to me.
>
Hm, yes, I will look on this ...
> How about other tools (tc,bridge,..) ? It would be nice to have the same
> option there as well.
>
Sure, good idea, I will try.
Thanks,
^ permalink raw reply
* Re: [PATCH 1/1] net/macb: fix compilation warning for print_hex_dump() called with skb->mac_header
From: Sergei Shtylyov @ 2014-12-11 14:39 UTC (permalink / raw)
To: Cyrille Pitchen, nicolas.ferre, davem, linux-arm-kernel, netdev,
soren.brinkmann
Cc: linux-kernel
In-Reply-To: <efa28485b430e77f5254248cb396da431d03fc5b.1418292741.git.cyrille.pitchen@atmel.com>
Hello.
On 12/11/2014 1:15 PM, Cyrille Pitchen wrote:
Citing the warning here would be a good idea.
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net] be2net: Export tunnel offloads only when a VxLAN tunnel is created
From: Sergei Shtylyov @ 2014-12-11 14:35 UTC (permalink / raw)
To: Sathya Perla, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <CF9D1877D81D214CB0CA0669EFAE020C68D24ADD@CMEXMB1.ad.emulex.com>
Hello.
On 12/11/2014 10:24 AM, Sathya Perla wrote:
>>> + netdev->hw_enc_features |= (NETIF_F_IP_CSUM |
>> NETIF_F_IPV6_CSUM |
>>> + NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_GSO_UDP_TUNNEL);
>> Please indent this properly:
>> netdev->hw_enc_features |= (NETIF_F_IP_CSUM |
>> NETIF_F_IPV6_CSUM |
>> NETIF_F_TSO | NETIF_F_TSO6 |
>> NETIF_F_GSO_UDP_TUNNEL);
> Oops, checkpatch didn't seem to catch this...will fix it up and send out a v2 right away...
> thanks!
Parens are not needed here as well.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH iproute2 v2] ip: Simplify executing ip cmd within network ns
From: Jiri Pirko @ 2014-12-11 14:21 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1418305103-5994-1-git-send-email-vadim4j@gmail.com>
Thu, Dec 11, 2014 at 02:38:23PM CET, vadim4j@gmail.com wrote:
>From: Vadim Kochan <vadim4j@gmail.com>
>
>Added new '-netns' option to simplify executing following cmd:
>
> ip netns exec NETNS ip OPTIONS COMMAND OBJECT
>
> to
>
> ip -n[etns] NETNS OPTIONS COMMAND OBJECT
>
>e.g.:
>
> ip -net vnet0 link add br0 type bridge
> ip -n vnet0 link
>
>Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
>---
>Changes v1 -> v2
> use -n[etns] option name: suggested by Nicolas Dichtel
> changed man ip.8 page
>
> ip/ip.c | 6 ++++++
> ip/ip_common.h | 1 +
> ip/ipnetns.c | 2 +-
> man/man8/ip.8 | 24 +++++++++++++++++++++++-
> 4 files changed, 31 insertions(+), 2 deletions(-)
>
>diff --git a/ip/ip.c b/ip/ip.c
>index 5f759d5..f3c2cdb 100644
>--- a/ip/ip.c
>+++ b/ip/ip.c
>@@ -262,6 +262,12 @@ int main(int argc, char **argv)
> rcvbuf = size;
> } else if (matches(opt, "-help") == 0) {
> usage();
>+ } else if (matches(opt, "-netns") == 0) {
>+ argc--;
>+ argv++;
>+ argv[0] = argv[1];
>+ argv[1] = basename;
>+ return netns_exec(argc, argv);
Can't the same functionality be done in the same ip process, meaning
without execvp ip again? It would seem clearer to me.
How about other tools (tc,bridge,..) ? It would be nice to have the same
option there as well.
> } else {
> fprintf(stderr, "Option \"%s\" is unknown, try \"ip -help\".\n", opt);
> exit(-1);
>diff --git a/ip/ip_common.h b/ip/ip_common.h
>index 75bfb82..d4f7e1f 100644
>--- a/ip/ip_common.h
>+++ b/ip/ip_common.h
>@@ -88,6 +88,7 @@ struct link_util
> struct link_util *get_link_kind(const char *kind);
> struct link_util *get_link_slave_kind(const char *slave_kind);
> int get_netns_fd(const char *name);
>+int netns_exec(int argc, char **argv);
>
> #ifndef INFINITY_LIFE_TIME
> #define INFINITY_LIFE_TIME 0xFFFFFFFFU
>diff --git a/ip/ipnetns.c b/ip/ipnetns.c
>index 1c8aa02..367841c 100644
>--- a/ip/ipnetns.c
>+++ b/ip/ipnetns.c
>@@ -129,7 +129,7 @@ static void bind_etc(const char *name)
> closedir(dir);
> }
>
>-static int netns_exec(int argc, char **argv)
>+int netns_exec(int argc, char **argv)
> {
> /* Setup the proper environment for apps that are not netns
> * aware, and execute a program in that environment.
>diff --git a/man/man8/ip.8 b/man/man8/ip.8
>index 2d42e98..389c808 100644
>--- a/man/man8/ip.8
>+++ b/man/man8/ip.8
>@@ -31,7 +31,8 @@ ip \- show / manipulate routing, devices, policy routing and tunnels
> \fB\-r\fR[\fIesolve\fR] |
> \fB\-f\fR[\fIamily\fR] {
> .BR inet " | " inet6 " | " ipx " | " dnet " | " link " } | "
>-\fB\-o\fR[\fIneline\fR] }
>+\fB\-o\fR[\fIneline\fR] |
>+\fB\-n\fR[\fIetns\fR] }
>
>
> .SH OPTIONS
>@@ -134,6 +135,27 @@ the output.
> use the system's name resolver to print DNS names instead of
> host addresses.
>
>+.TP
>+.BR "\-n" , " \-net" , " \-netns " <NETNS>
>+executes the following
>+.RI "[ " OPTIONS " ] " OBJECT " { " COMMAND " | "
>+.BR help " }"
>+in the specified network namespace
>+.IR NETNS .
>+Actually it just simplifies executing of:
>+
>+.B ip netns exec
>+.IR NETNS
>+.B ip
>+.RI "[ " OPTIONS " ] " OBJECT " { " COMMAND " | "
>+.BR help " }"
>+
>+to
>+
>+.B ip
>+.RI "-n[etns] " NETNS " [ " OPTIONS " ] " OBJECT " { " COMMAND " | "
>+.BR help " }"
>+
> .SH IP - COMMAND SYNTAX
>
> .SS
>--
>2.1.3
>
>--
>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 v7 2/3] net: Add Keystone NetCP ethernet driver
From: Murali Karicheri @ 2014-12-11 14:14 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <20141210.204110.618599360537141819.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 12/10/2014 08:41 PM, David Miller wrote:
> From: Murali Karicheri<m-karicheri2-l0cyMroinI0@public.gmane.org>
> Date: Wed, 10 Dec 2014 16:31:02 -0500
>
>> Are you referring to the static code analyser sparse that is invoked
>> through?
>
> You have to explicitly enable endian checking, it's not on by
> default.
Thanks David and others who responded. Let me do this and resolve any
warning before the next post.
BTW, could you provide any suggestions that would help us merge this
series to upstream? This has been sitting on this list for a while now.
Thanks and regards,
--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
From: Smart Weblications GmbH - Florian Wiessner @ 2014-12-11 14:04 UTC (permalink / raw)
To: Julian Anastasov
Cc: Steffen Klassert, netdev, LKML, stable, Simon Horman, lvs-devel
In-Reply-To: <alpine.LFD.2.11.1412102331230.4043@ja.home.ssi.bg>
Hi,
Am 10.12.2014 22:41, schrieb Julian Anastasov:>
> Hello,
>
> On Tue, 9 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:
>
>> I rebuild everything with the two provided patches and still get:
>>
>> [ 512.475449] BUG: unable to handle kernel NULL pointer dereference at
>> 0000000000000014
>> [ 512.481277] IP: [<ffffffffa013d470>] nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
>
> Same place, hm...
>
>> [ 512.485323] CPU: 4 PID: 28142 Comm: vsftpd Not tainted 3.12.33 #5
>
> Above "#5" is same as previous oops. It means kernel
> is not updated. Or you updated only the IPVS modules after
> applying the both patches?
I did it with make-kpkg --initrd linux_image which only rebuilt the modules,
correct. I can retry with make clean before building the package
>
> You can also try without FTP tests to see if there
> are oopses in xfrm, so that we can close this topic and then
> to continue for the FTP problem on IPVS lists without
> bothering non-IPVS people.
>
yeah, it seems that the xfrm issue is away.
--
Mit freundlichen Grüßen,
Florian Wiessner
Smart Weblications GmbH
Martinsberger Str. 1
D-95119 Naila
fon.: +49 9282 9638 200
fax.: +49 9282 9638 205
24/7: +49 900 144 000 00 - 0,99 EUR/Min*
http://www.smart-weblications.de
--
Sitz der Gesellschaft: Naila
Geschäftsführer: Florian Wiessner
HRB-Nr.: HRB 3840 Amtsgericht Hof
*aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz
^ permalink raw reply
* RE: [RFC PATCH net-next 1/1] net: Support for switch port configuration
From: Varlese, Marco @ 2014-12-11 13:55 UTC (permalink / raw)
To: Jiri Pirko
Cc: John Fastabend, netdev@vger.kernel.org,
stephen@networkplumber.org, Fastabend, John R,
roopa@cumulusnetworks.com, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <20141211130830.GA1912@nanopsycho.orion>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Jiri Pirko
> Sent: Thursday, December 11, 2014 1:09 PM
> To: Varlese, Marco
> Cc: John Fastabend; netdev@vger.kernel.org;
> stephen@networkplumber.org; Fastabend, John R;
> roopa@cumulusnetworks.com; sfeldma@gmail.com; linux-
> kernel@vger.kernel.org
> Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port
> configuration
>
> Thu, Dec 11, 2014 at 01:02:36PM CET, marco.varlese@intel.com wrote:
> >> -----Original Message-----
> >> From: Jiri Pirko [mailto:jiri@resnulli.us]
> >> Sent: Thursday, December 11, 2014 11:01 AM
> >> To: Varlese, Marco
> >> Cc: John Fastabend; netdev@vger.kernel.org;
> >> stephen@networkplumber.org; Fastabend, John R;
> >> roopa@cumulusnetworks.com; sfeldma@gmail.com; linux-
> >> kernel@vger.kernel.org
> >> Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port
> >> configuration
> >>
> >> Thu, Dec 11, 2014 at 10:59:42AM CET, marco.varlese@intel.com wrote:
> >> >> -----Original Message-----
> >> >> From: John Fastabend [mailto:john.fastabend@gmail.com]
> >> >> Sent: Wednesday, December 10, 2014 5:04 PM
> >> >> To: Jiri Pirko
> >> >> Cc: Varlese, Marco; netdev@vger.kernel.org;
> >> >> stephen@networkplumber.org; Fastabend, John R;
> >> >> roopa@cumulusnetworks.com; sfeldma@gmail.com; linux-
> >> >> kernel@vger.kernel.org
> >> >> Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port
> >> >> configuration
> >> >>
> >> >> On 12/10/2014 08:50 AM, Jiri Pirko wrote:
> >> >> > Wed, Dec 10, 2014 at 05:23:40PM CET, marco.varlese@intel.com
> wrote:
> >> >> >> From: Marco Varlese <marco.varlese@intel.com>
> >> >> >>
> >> >> >> Switch hardware offers a list of attributes that are
> >> >> >> configurable on a per port basis.
> >> >> >> This patch provides a mechanism to configure switch ports by
> >> >> >> adding an NDO for setting specific values to specific attributes.
> >> >> >> There will be a separate patch that extends iproute2 to call
> >> >> >> the new NDO.
> >> >> >
> >> >> >
> >> >> > What are these attributes? Can you give some examples. I'm
> >> >> > asking because there is a plan to pass generic attributes to
> >> >> > switch ports replacing current specific
> >> >> > ndo_switch_port_stp_update. In this case, bridge is setting that
> attribute.
> >> >> >
> >> >> > Is there need to set something directly from userspace or does
> >> >> > it make rather sense to use involved bridge/ovs/bond ? I think
> >> >> > that both will be needed.
> >> >>
> >> >> +1
> >> >>
> >> >> I think for many attributes it would be best to have both. The in
> >> >> kernel callers and netlink userspace can use the same driver ndo_ops.
> >> >>
> >> >> But then we don't _require_ any specific bridge/ovs/etc module.
> >> >> And we may have some attributes that are not specific to any
> >> >> existing software module. I'm guessing Marco has some examples of
> these.
> >> >>
> >> >> [...]
> >> >>
> >> >>
> >> >> --
> >> >> John Fastabend Intel Corporation
> >> >
> >> >We do have a need to configure the attributes directly from
> >> >user-space and
> >> I have identified the tool to do that in iproute2.
> >> >
> >> >An example of attributes are:
> >> >* enabling/disabling of learning of source addresses on a given port
> >> >(you can imagine the attribute called LEARNING for example);
> >> >* internal loopback control (i.e. LOOPBACK) which will control how
> >> >the flow of traffic behaves from the switch fabric towards an egress
> >> >port;
> >> >* flooding for broadcast/multicast/unicast type of packets (i.e.
> >> >BFLOODING, MFLOODING, UFLOODING);
> >> >
> >> >Some attributes would be of the type enabled/disabled while other
> >> >will
> >> allow specific values to allow the user to configure different
> >> behaviours of that feature on that particular port on that platform.
> >> >
> >> >One thing to mention - as John stated as well - there might be some
> >> attributes that are not specific to any software module but rather
> >> have to do with the actual hardware/platform to configure.
> >> >
> >> >I hope this clarifies some points.
> >>
> >> It does. Makes sense. We need to expose this attr set/get for both
> >> in-kernel and userspace use cases.
> >>
> >> Please adjust you patch for this. Also, as a second patch, it would
> >> be great if you can convert ndo_switch_port_stp_update to this new ndo.
> >>
> >> Thanks.
> >>
> >>
> >
> >I was thinking of leaving the get side of things implemented via sysfs rather
> than implementing an NDO for it. Would this not be appropriate?
>
> I believe that it is preferred to have both get and set exposed via ndo and
> netlink. It can be exposed via sysfs as well, but it is "nice to have"
> not "must have"
>
I'll add the get ndo to my patch now. Thanks.
^ permalink raw reply
* [PATCH iproute2 v2] ip: Simplify executing ip cmd within network ns
From: Vadim Kochan @ 2014-12-11 13:38 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
From: Vadim Kochan <vadim4j@gmail.com>
Added new '-netns' option to simplify executing following cmd:
ip netns exec NETNS ip OPTIONS COMMAND OBJECT
to
ip -n[etns] NETNS OPTIONS COMMAND OBJECT
e.g.:
ip -net vnet0 link add br0 type bridge
ip -n vnet0 link
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
Changes v1 -> v2
use -n[etns] option name: suggested by Nicolas Dichtel
changed man ip.8 page
ip/ip.c | 6 ++++++
ip/ip_common.h | 1 +
ip/ipnetns.c | 2 +-
man/man8/ip.8 | 24 +++++++++++++++++++++++-
4 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/ip/ip.c b/ip/ip.c
index 5f759d5..f3c2cdb 100644
--- a/ip/ip.c
+++ b/ip/ip.c
@@ -262,6 +262,12 @@ int main(int argc, char **argv)
rcvbuf = size;
} else if (matches(opt, "-help") == 0) {
usage();
+ } else if (matches(opt, "-netns") == 0) {
+ argc--;
+ argv++;
+ argv[0] = argv[1];
+ argv[1] = basename;
+ return netns_exec(argc, argv);
} else {
fprintf(stderr, "Option \"%s\" is unknown, try \"ip -help\".\n", opt);
exit(-1);
diff --git a/ip/ip_common.h b/ip/ip_common.h
index 75bfb82..d4f7e1f 100644
--- a/ip/ip_common.h
+++ b/ip/ip_common.h
@@ -88,6 +88,7 @@ struct link_util
struct link_util *get_link_kind(const char *kind);
struct link_util *get_link_slave_kind(const char *slave_kind);
int get_netns_fd(const char *name);
+int netns_exec(int argc, char **argv);
#ifndef INFINITY_LIFE_TIME
#define INFINITY_LIFE_TIME 0xFFFFFFFFU
diff --git a/ip/ipnetns.c b/ip/ipnetns.c
index 1c8aa02..367841c 100644
--- a/ip/ipnetns.c
+++ b/ip/ipnetns.c
@@ -129,7 +129,7 @@ static void bind_etc(const char *name)
closedir(dir);
}
-static int netns_exec(int argc, char **argv)
+int netns_exec(int argc, char **argv)
{
/* Setup the proper environment for apps that are not netns
* aware, and execute a program in that environment.
diff --git a/man/man8/ip.8 b/man/man8/ip.8
index 2d42e98..389c808 100644
--- a/man/man8/ip.8
+++ b/man/man8/ip.8
@@ -31,7 +31,8 @@ ip \- show / manipulate routing, devices, policy routing and tunnels
\fB\-r\fR[\fIesolve\fR] |
\fB\-f\fR[\fIamily\fR] {
.BR inet " | " inet6 " | " ipx " | " dnet " | " link " } | "
-\fB\-o\fR[\fIneline\fR] }
+\fB\-o\fR[\fIneline\fR] |
+\fB\-n\fR[\fIetns\fR] }
.SH OPTIONS
@@ -134,6 +135,27 @@ the output.
use the system's name resolver to print DNS names instead of
host addresses.
+.TP
+.BR "\-n" , " \-net" , " \-netns " <NETNS>
+executes the following
+.RI "[ " OPTIONS " ] " OBJECT " { " COMMAND " | "
+.BR help " }"
+in the specified network namespace
+.IR NETNS .
+Actually it just simplifies executing of:
+
+.B ip netns exec
+.IR NETNS
+.B ip
+.RI "[ " OPTIONS " ] " OBJECT " { " COMMAND " | "
+.BR help " }"
+
+to
+
+.B ip
+.RI "-n[etns] " NETNS " [ " OPTIONS " ] " OBJECT " { " COMMAND " | "
+.BR help " }"
+
.SH IP - COMMAND SYNTAX
.SS
--
2.1.3
^ permalink raw reply related
* Re: [PATCH iproute2] ip: Simplify executing ip cmd within namespace
From: vadim4j @ 2014-12-11 13:02 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: vadim4j, netdev
In-Reply-To: <54899309.7050109@6wind.com>
On Thu, Dec 11, 2014 at 01:50:17PM +0100, Nicolas Dichtel wrote:
> Le 11/12/2014 11:57, vadim4j@gmail.com a écrit :
> >On Thu, Dec 11, 2014 at 11:58:21AM +0100, Nicolas Dichtel wrote:
> >>Le 10/12/2014 23:56, Vadim Kochan a écrit :
> >>>From: Vadim Kochan <vadim4j@gmail.com>
> >>>
> >>>Added new '-ns' option to simplify executing following cmd:
> >>>
> >>> ip netns exec NETNS ip OPTIONS COMMAND OBJECT
> >>>
> >>> to
> >>>
> >>> ip -ns NETNS OPTIONS COMMAND OBJECT
> >>>
> >>>e.g.:
> >>>
> >>> ip -ns vnet0 link add br0 type bridge
> >>>
> >>>Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
> >>>---
> >>>May be new option should have better name than '-ns' ?
> >>What about 'ip -netns' to be explicit like other options?
> >>user may still use 'ip -n' at the end.
> >>
> >>
> >>Regards,
> >>Nicolas
> >
> >May be left '-n' for some other future option, but use the following
> Options parsing in iproute2 will match -netns when typing -n because there
> is no other options that begin with a 'n' (I've done a quick look, maybe I've
> missed one).
> Like -d which matches -details, etc.
>
> >options: -net[ns] and -ns ? What do you think ?
> One option is enough. '-netns' is an explicit reference to 'ip netns'.
>
>
> Regards,
> Nicolas
OK, I agree.
I will re-work and resend v2.
Thanks,
^ permalink raw reply
* Re: [RFC PATCH net-next 1/1] net: Support for switch port configuration
From: Jiri Pirko @ 2014-12-11 13:08 UTC (permalink / raw)
To: Varlese, Marco
Cc: John Fastabend, netdev@vger.kernel.org,
stephen@networkplumber.org, Fastabend, John R,
roopa@cumulusnetworks.com, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <C4896FB061E7DE4AAC93031BDCA044B104AC3E77@IRSMSX108.ger.corp.intel.com>
Thu, Dec 11, 2014 at 01:02:36PM CET, marco.varlese@intel.com wrote:
>> -----Original Message-----
>> From: Jiri Pirko [mailto:jiri@resnulli.us]
>> Sent: Thursday, December 11, 2014 11:01 AM
>> To: Varlese, Marco
>> Cc: John Fastabend; netdev@vger.kernel.org;
>> stephen@networkplumber.org; Fastabend, John R;
>> roopa@cumulusnetworks.com; sfeldma@gmail.com; linux-
>> kernel@vger.kernel.org
>> Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port
>> configuration
>>
>> Thu, Dec 11, 2014 at 10:59:42AM CET, marco.varlese@intel.com wrote:
>> >> -----Original Message-----
>> >> From: John Fastabend [mailto:john.fastabend@gmail.com]
>> >> Sent: Wednesday, December 10, 2014 5:04 PM
>> >> To: Jiri Pirko
>> >> Cc: Varlese, Marco; netdev@vger.kernel.org;
>> >> stephen@networkplumber.org; Fastabend, John R;
>> >> roopa@cumulusnetworks.com; sfeldma@gmail.com; linux-
>> >> kernel@vger.kernel.org
>> >> Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port
>> >> configuration
>> >>
>> >> On 12/10/2014 08:50 AM, Jiri Pirko wrote:
>> >> > Wed, Dec 10, 2014 at 05:23:40PM CET, marco.varlese@intel.com wrote:
>> >> >> From: Marco Varlese <marco.varlese@intel.com>
>> >> >>
>> >> >> Switch hardware offers a list of attributes that are configurable
>> >> >> on a per port basis.
>> >> >> This patch provides a mechanism to configure switch ports by
>> >> >> adding an NDO for setting specific values to specific attributes.
>> >> >> There will be a separate patch that extends iproute2 to call the
>> >> >> new NDO.
>> >> >
>> >> >
>> >> > What are these attributes? Can you give some examples. I'm asking
>> >> > because there is a plan to pass generic attributes to switch ports
>> >> > replacing current specific ndo_switch_port_stp_update. In this
>> >> > case, bridge is setting that attribute.
>> >> >
>> >> > Is there need to set something directly from userspace or does it
>> >> > make rather sense to use involved bridge/ovs/bond ? I think that
>> >> > both will be needed.
>> >>
>> >> +1
>> >>
>> >> I think for many attributes it would be best to have both. The in
>> >> kernel callers and netlink userspace can use the same driver ndo_ops.
>> >>
>> >> But then we don't _require_ any specific bridge/ovs/etc module. And
>> >> we may have some attributes that are not specific to any existing
>> >> software module. I'm guessing Marco has some examples of these.
>> >>
>> >> [...]
>> >>
>> >>
>> >> --
>> >> John Fastabend Intel Corporation
>> >
>> >We do have a need to configure the attributes directly from user-space and
>> I have identified the tool to do that in iproute2.
>> >
>> >An example of attributes are:
>> >* enabling/disabling of learning of source addresses on a given port
>> >(you can imagine the attribute called LEARNING for example);
>> >* internal loopback control (i.e. LOOPBACK) which will control how the
>> >flow of traffic behaves from the switch fabric towards an egress port;
>> >* flooding for broadcast/multicast/unicast type of packets (i.e.
>> >BFLOODING, MFLOODING, UFLOODING);
>> >
>> >Some attributes would be of the type enabled/disabled while other will
>> allow specific values to allow the user to configure different behaviours of
>> that feature on that particular port on that platform.
>> >
>> >One thing to mention - as John stated as well - there might be some
>> attributes that are not specific to any software module but rather have to do
>> with the actual hardware/platform to configure.
>> >
>> >I hope this clarifies some points.
>>
>> It does. Makes sense. We need to expose this attr set/get for both in-kernel
>> and userspace use cases.
>>
>> Please adjust you patch for this. Also, as a second patch, it would be great if
>> you can convert ndo_switch_port_stp_update to this new ndo.
>>
>> Thanks.
>>
>>
>
>I was thinking of leaving the get side of things implemented via sysfs rather than implementing an NDO for it. Would this not be appropriate?
I believe that it is preferred to have both get and set exposed via ndo
and netlink. It can be exposed via sysfs as well, but it is "nice to have"
not "must have"
^ permalink raw reply
* Re: [PATCH iproute2] ip: Simplify executing ip cmd within namespace
From: Nicolas Dichtel @ 2014-12-11 12:50 UTC (permalink / raw)
To: vadim4j; +Cc: netdev
In-Reply-To: <20141211105733.GA17601@angus-think.wlc.globallogic.com>
Le 11/12/2014 11:57, vadim4j@gmail.com a écrit :
> On Thu, Dec 11, 2014 at 11:58:21AM +0100, Nicolas Dichtel wrote:
>> Le 10/12/2014 23:56, Vadim Kochan a écrit :
>>> From: Vadim Kochan <vadim4j@gmail.com>
>>>
>>> Added new '-ns' option to simplify executing following cmd:
>>>
>>> ip netns exec NETNS ip OPTIONS COMMAND OBJECT
>>>
>>> to
>>>
>>> ip -ns NETNS OPTIONS COMMAND OBJECT
>>>
>>> e.g.:
>>>
>>> ip -ns vnet0 link add br0 type bridge
>>>
>>> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
>>> ---
>>> May be new option should have better name than '-ns' ?
>> What about 'ip -netns' to be explicit like other options?
>> user may still use 'ip -n' at the end.
>>
>>
>> Regards,
>> Nicolas
>
> May be left '-n' for some other future option, but use the following
Options parsing in iproute2 will match -netns when typing -n because there
is no other options that begin with a 'n' (I've done a quick look, maybe I've
missed one).
Like -d which matches -details, etc.
> options: -net[ns] and -ns ? What do you think ?
One option is enough. '-netns' is an explicit reference to 'ip netns'.
Regards,
Nicolas
^ permalink raw reply
* Re: [PULL] virtio: virtio 1.0 support, misc patches
From: Michael S. Tsirkin @ 2014-12-11 12:14 UTC (permalink / raw)
To: Linus Torvalds
Cc: sergei.shtylyov, kvm, netdev, linux-kernel, virtualization,
pbonzini, ben, David Miller, thuth
In-Reply-To: <20141211120248.GA8838@redhat.com>
On Thu, Dec 11, 2014 at 02:02:48PM +0200, Michael S. Tsirkin wrote:
> The following changes since commit b2776bf7149bddd1f4161f14f79520f17fc1d71d:
>
> Linux 3.18 (2014-12-07 14:21:05 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
>
> for you to fetch changes up to 803cd18f7b5e6c7ad6bee9571ae8f4450190ab58:
Actually the commit hash in this mail is wrong:
The correct one is
f01a2a811ae04124fc9382925038fcbbd2f0b7c8
the reason I got this wrong is I prepared the pull request mail several
days ago, and since then I have rebased, pushed, and several people
tested this correct latest hash.
It's all signed correctly, so
Linus, do I need to resend?
Sorry about the noise.
>
> virtio_ccw: finalize_features error handling (2014-12-09 16:32:41 +0200)
>
> Note: some net drivers are affected by these patches.
> David said he's fine with merging these patches through
> my tree.
> Rusty's on vacation, he acked using my tree for these, too.
>
> ----------------------------------------------------------------
> virtio: virtio 1.0 support, misc patches
>
> This adds a lot of infrastructure for virtio 1.0 support.
> Notable missing pieces: virtio pci, virtio balloon (needs spec extension),
> vhost scsi.
>
> Plus, there are some minor fixes in a couple of places.
>
> Cc: David Miller <davem@davemloft.net>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> ----------------------------------------------------------------
> Cornelia Huck (4):
> virtio: allow transports to get avail/used addresses
> KVM: s390: virtio-ccw revision 1 SET_VQ
> KVM: s390: enable virtio-ccw revision 1
> virtio_ccw: finalize_features error handling
>
> Jason Wang (1):
> vhost: remove unnecessary forward declarations in vhost.h
>
> Michael S. Tsirkin (64):
> virtio: add low-level APIs for feature bits
> virtio: use u32, not bitmap for features
> mic_virtio: robust feature array size calculation
> virtio: add support for 64 bit features.
> virtio: assert 32 bit features in transports
> virtio_ccw: add support for 64 bit features.
> virtio: add virtio 1.0 feature bit
> virtio: memory access APIs
> virtio_ring: switch to new memory access APIs
> virtio_config: endian conversion for v1.0
> virtio: set FEATURES_OK
> virtio: simplify feature bit handling
> virtio: add legacy feature table support
> virtio_net: v1.0 endianness
> virtio_blk: v1.0 support
> KVM: s390 allow virtio_ccw status writes to fail
> virtio_blk: make serial attribute static
> virtio_blk: fix race at module removal
> virtio_net: pass vi around
> virtio_net: get rid of virtio_net_hdr/skb_vnet_hdr
> virtio_net: stricter short buffer length checks
> virtio_net: bigger header when VERSION_1 is set
> virtio_net: disable mac write for virtio 1.0
> virtio_net: enable v1.0 support
> vhost: make features 64 bit
> vhost: add memory access wrappers
> vhost/net: force len for TX to host endian
> vhost: switch to __get/__put_user exclusively
> vhost: virtio 1.0 endian-ness support
> vhost/net: virtio 1.0 byte swap
> vhost/net: larger header for virtio 1.0
> vhost/net: enable virtio 1.0
> tun: move internal flag defines out of uapi
> tun: drop most type defines
> tun: add VNET_LE flag
> tun: TUN_VNET_LE support, fix sparse warnings for virtio headers
> macvtap: TUN_VNET_LE support
> virtio_scsi: v1.0 support
> virtio_scsi: move to uapi
> virtio_scsi: export to userspace
> vhost/scsi: partial virtio 1.0 support
> af_packet: virtio 1.0 stubs
> virtio_console: virtio 1.0 support
> virtio_balloon: add legacy_only flag
> virtio: make VIRTIO_F_VERSION_1 a transport bit
> virtio: drop VIRTIO_F_VERSION_1 from drivers
> virtio_console: fix sparse warnings
> virtio: add API to detect legacy devices
> virtio_ccw: legacy: don't negotiate rev 1/features
> virtio: allow finalize_features to fail
> virtio_ccw: rev 1 devices set VIRTIO_F_VERSION_1
> virtio_balloon: drop legacy_only driver flag
> virtio: drop legacy_only driver flag
> virtio_pci: add isr field
> virtio_pci: fix coding style for structs
> virtio_pci: free up vq->priv
> virtio_pci: use priv for vq notification
> virtio_pci: delete vqs indirectly
> virtio_pci: setup vqs indirectly
> virtio_pci: setup config vector indirectly
> virtio_pci: split out legacy device support
> virtio_pci: update file descriptions and copyright
> virtio_pci: rename virtio_pci -> virtio_pci_common
> virtio_ccw: future-proof finalize_features
>
> Thomas Huth (1):
> KVM: s390: Set virtio-ccw transport revision
>
> drivers/vhost/vhost.h | 41 +-
> drivers/virtio/virtio_pci_common.h | 136 ++++++
> include/linux/virtio.h | 12 +-
> include/linux/virtio_byteorder.h | 59 +++
> include/linux/virtio_config.h | 103 ++++-
> include/uapi/linux/if_tun.h | 17 +-
> include/uapi/linux/virtio_blk.h | 15 +-
> include/uapi/linux/virtio_config.h | 9 +-
> include/uapi/linux/virtio_console.h | 7 +-
> include/uapi/linux/virtio_net.h | 15 +-
> include/uapi/linux/virtio_ring.h | 45 +-
> include/{ => uapi}/linux/virtio_scsi.h | 106 ++---
> include/uapi/linux/virtio_types.h | 46 ++
> tools/virtio/linux/virtio.h | 22 +-
> tools/virtio/linux/virtio_config.h | 2 +-
> drivers/block/virtio_blk.c | 74 +--
> drivers/char/virtio_console.c | 39 +-
> drivers/lguest/lguest_device.c | 17 +-
> drivers/misc/mic/card/mic_virtio.c | 14 +-
> drivers/net/macvtap.c | 68 ++-
> drivers/net/tun.c | 168 +++----
> drivers/net/virtio_net.c | 161 +++----
> drivers/remoteproc/remoteproc_virtio.c | 11 +-
> drivers/s390/kvm/kvm_virtio.c | 11 +-
> drivers/s390/kvm/virtio_ccw.c | 203 +++++++--
> drivers/scsi/virtio_scsi.c | 50 +-
> drivers/vhost/net.c | 31 +-
> drivers/vhost/scsi.c | 22 +-
> drivers/vhost/vhost.c | 93 ++--
> drivers/virtio/virtio.c | 102 ++++-
> drivers/virtio/virtio_mmio.c | 17 +-
> drivers/virtio/virtio_pci.c | 802 ---------------------------------
> drivers/virtio/virtio_pci_common.c | 464 +++++++++++++++++++
> drivers/virtio/virtio_pci_legacy.c | 326 ++++++++++++++
> drivers/virtio/virtio_ring.c | 109 +++--
> net/packet/af_packet.c | 35 +-
> tools/virtio/virtio_test.c | 5 +-
> tools/virtio/vringh_test.c | 16 +-
> drivers/virtio/Makefile | 1 +
> include/uapi/linux/Kbuild | 2 +
> 40 files changed, 2048 insertions(+), 1428 deletions(-)
> create mode 100644 drivers/virtio/virtio_pci_common.h
> create mode 100644 include/linux/virtio_byteorder.h
> rename include/{ => uapi}/linux/virtio_scsi.h (73%)
> create mode 100644 include/uapi/linux/virtio_types.h
> delete mode 100644 drivers/virtio/virtio_pci.c
> create mode 100644 drivers/virtio/virtio_pci_common.c
> create mode 100644 drivers/virtio/virtio_pci_legacy.c
^ permalink raw reply
* RE: [RFC PATCH net-next 1/1] net: Support for switch port configuration
From: Varlese, Marco @ 2014-12-11 12:02 UTC (permalink / raw)
To: Jiri Pirko
Cc: John Fastabend, netdev@vger.kernel.org,
stephen@networkplumber.org, Fastabend, John R,
roopa@cumulusnetworks.com, sfeldma@gmail.com,
linux-kernel@vger.kernel.org
In-Reply-To: <20141211110115.GA1979@nanopsycho.lan>
> -----Original Message-----
> From: Jiri Pirko [mailto:jiri@resnulli.us]
> Sent: Thursday, December 11, 2014 11:01 AM
> To: Varlese, Marco
> Cc: John Fastabend; netdev@vger.kernel.org;
> stephen@networkplumber.org; Fastabend, John R;
> roopa@cumulusnetworks.com; sfeldma@gmail.com; linux-
> kernel@vger.kernel.org
> Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port
> configuration
>
> Thu, Dec 11, 2014 at 10:59:42AM CET, marco.varlese@intel.com wrote:
> >> -----Original Message-----
> >> From: John Fastabend [mailto:john.fastabend@gmail.com]
> >> Sent: Wednesday, December 10, 2014 5:04 PM
> >> To: Jiri Pirko
> >> Cc: Varlese, Marco; netdev@vger.kernel.org;
> >> stephen@networkplumber.org; Fastabend, John R;
> >> roopa@cumulusnetworks.com; sfeldma@gmail.com; linux-
> >> kernel@vger.kernel.org
> >> Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port
> >> configuration
> >>
> >> On 12/10/2014 08:50 AM, Jiri Pirko wrote:
> >> > Wed, Dec 10, 2014 at 05:23:40PM CET, marco.varlese@intel.com wrote:
> >> >> From: Marco Varlese <marco.varlese@intel.com>
> >> >>
> >> >> Switch hardware offers a list of attributes that are configurable
> >> >> on a per port basis.
> >> >> This patch provides a mechanism to configure switch ports by
> >> >> adding an NDO for setting specific values to specific attributes.
> >> >> There will be a separate patch that extends iproute2 to call the
> >> >> new NDO.
> >> >
> >> >
> >> > What are these attributes? Can you give some examples. I'm asking
> >> > because there is a plan to pass generic attributes to switch ports
> >> > replacing current specific ndo_switch_port_stp_update. In this
> >> > case, bridge is setting that attribute.
> >> >
> >> > Is there need to set something directly from userspace or does it
> >> > make rather sense to use involved bridge/ovs/bond ? I think that
> >> > both will be needed.
> >>
> >> +1
> >>
> >> I think for many attributes it would be best to have both. The in
> >> kernel callers and netlink userspace can use the same driver ndo_ops.
> >>
> >> But then we don't _require_ any specific bridge/ovs/etc module. And
> >> we may have some attributes that are not specific to any existing
> >> software module. I'm guessing Marco has some examples of these.
> >>
> >> [...]
> >>
> >>
> >> --
> >> John Fastabend Intel Corporation
> >
> >We do have a need to configure the attributes directly from user-space and
> I have identified the tool to do that in iproute2.
> >
> >An example of attributes are:
> >* enabling/disabling of learning of source addresses on a given port
> >(you can imagine the attribute called LEARNING for example);
> >* internal loopback control (i.e. LOOPBACK) which will control how the
> >flow of traffic behaves from the switch fabric towards an egress port;
> >* flooding for broadcast/multicast/unicast type of packets (i.e.
> >BFLOODING, MFLOODING, UFLOODING);
> >
> >Some attributes would be of the type enabled/disabled while other will
> allow specific values to allow the user to configure different behaviours of
> that feature on that particular port on that platform.
> >
> >One thing to mention - as John stated as well - there might be some
> attributes that are not specific to any software module but rather have to do
> with the actual hardware/platform to configure.
> >
> >I hope this clarifies some points.
>
> It does. Makes sense. We need to expose this attr set/get for both in-kernel
> and userspace use cases.
>
> Please adjust you patch for this. Also, as a second patch, it would be great if
> you can convert ndo_switch_port_stp_update to this new ndo.
>
> Thanks.
>
>
I was thinking of leaving the get side of things implemented via sysfs rather than implementing an NDO for it. Would this not be appropriate?
- - -
Marco Varlese
^ permalink raw reply
* [PULL] virtio: virtio 1.0 support, misc patches
From: Michael S. Tsirkin @ 2014-12-11 12:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: sergei.shtylyov, kvm, mst, netdev, linux-kernel, virtualization,
pbonzini, ben, David Miller, thuth
The following changes since commit b2776bf7149bddd1f4161f14f79520f17fc1d71d:
Linux 3.18 (2014-12-07 14:21:05 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
for you to fetch changes up to 803cd18f7b5e6c7ad6bee9571ae8f4450190ab58:
virtio_ccw: finalize_features error handling (2014-12-09 16:32:41 +0200)
Note: some net drivers are affected by these patches.
David said he's fine with merging these patches through
my tree.
Rusty's on vacation, he acked using my tree for these, too.
----------------------------------------------------------------
virtio: virtio 1.0 support, misc patches
This adds a lot of infrastructure for virtio 1.0 support.
Notable missing pieces: virtio pci, virtio balloon (needs spec extension),
vhost scsi.
Plus, there are some minor fixes in a couple of places.
Cc: David Miller <davem@davemloft.net>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
----------------------------------------------------------------
Cornelia Huck (4):
virtio: allow transports to get avail/used addresses
KVM: s390: virtio-ccw revision 1 SET_VQ
KVM: s390: enable virtio-ccw revision 1
virtio_ccw: finalize_features error handling
Jason Wang (1):
vhost: remove unnecessary forward declarations in vhost.h
Michael S. Tsirkin (64):
virtio: add low-level APIs for feature bits
virtio: use u32, not bitmap for features
mic_virtio: robust feature array size calculation
virtio: add support for 64 bit features.
virtio: assert 32 bit features in transports
virtio_ccw: add support for 64 bit features.
virtio: add virtio 1.0 feature bit
virtio: memory access APIs
virtio_ring: switch to new memory access APIs
virtio_config: endian conversion for v1.0
virtio: set FEATURES_OK
virtio: simplify feature bit handling
virtio: add legacy feature table support
virtio_net: v1.0 endianness
virtio_blk: v1.0 support
KVM: s390 allow virtio_ccw status writes to fail
virtio_blk: make serial attribute static
virtio_blk: fix race at module removal
virtio_net: pass vi around
virtio_net: get rid of virtio_net_hdr/skb_vnet_hdr
virtio_net: stricter short buffer length checks
virtio_net: bigger header when VERSION_1 is set
virtio_net: disable mac write for virtio 1.0
virtio_net: enable v1.0 support
vhost: make features 64 bit
vhost: add memory access wrappers
vhost/net: force len for TX to host endian
vhost: switch to __get/__put_user exclusively
vhost: virtio 1.0 endian-ness support
vhost/net: virtio 1.0 byte swap
vhost/net: larger header for virtio 1.0
vhost/net: enable virtio 1.0
tun: move internal flag defines out of uapi
tun: drop most type defines
tun: add VNET_LE flag
tun: TUN_VNET_LE support, fix sparse warnings for virtio headers
macvtap: TUN_VNET_LE support
virtio_scsi: v1.0 support
virtio_scsi: move to uapi
virtio_scsi: export to userspace
vhost/scsi: partial virtio 1.0 support
af_packet: virtio 1.0 stubs
virtio_console: virtio 1.0 support
virtio_balloon: add legacy_only flag
virtio: make VIRTIO_F_VERSION_1 a transport bit
virtio: drop VIRTIO_F_VERSION_1 from drivers
virtio_console: fix sparse warnings
virtio: add API to detect legacy devices
virtio_ccw: legacy: don't negotiate rev 1/features
virtio: allow finalize_features to fail
virtio_ccw: rev 1 devices set VIRTIO_F_VERSION_1
virtio_balloon: drop legacy_only driver flag
virtio: drop legacy_only driver flag
virtio_pci: add isr field
virtio_pci: fix coding style for structs
virtio_pci: free up vq->priv
virtio_pci: use priv for vq notification
virtio_pci: delete vqs indirectly
virtio_pci: setup vqs indirectly
virtio_pci: setup config vector indirectly
virtio_pci: split out legacy device support
virtio_pci: update file descriptions and copyright
virtio_pci: rename virtio_pci -> virtio_pci_common
virtio_ccw: future-proof finalize_features
Thomas Huth (1):
KVM: s390: Set virtio-ccw transport revision
drivers/vhost/vhost.h | 41 +-
drivers/virtio/virtio_pci_common.h | 136 ++++++
include/linux/virtio.h | 12 +-
include/linux/virtio_byteorder.h | 59 +++
include/linux/virtio_config.h | 103 ++++-
include/uapi/linux/if_tun.h | 17 +-
include/uapi/linux/virtio_blk.h | 15 +-
include/uapi/linux/virtio_config.h | 9 +-
include/uapi/linux/virtio_console.h | 7 +-
include/uapi/linux/virtio_net.h | 15 +-
include/uapi/linux/virtio_ring.h | 45 +-
include/{ => uapi}/linux/virtio_scsi.h | 106 ++---
include/uapi/linux/virtio_types.h | 46 ++
tools/virtio/linux/virtio.h | 22 +-
tools/virtio/linux/virtio_config.h | 2 +-
drivers/block/virtio_blk.c | 74 +--
drivers/char/virtio_console.c | 39 +-
drivers/lguest/lguest_device.c | 17 +-
drivers/misc/mic/card/mic_virtio.c | 14 +-
drivers/net/macvtap.c | 68 ++-
drivers/net/tun.c | 168 +++----
drivers/net/virtio_net.c | 161 +++----
drivers/remoteproc/remoteproc_virtio.c | 11 +-
drivers/s390/kvm/kvm_virtio.c | 11 +-
drivers/s390/kvm/virtio_ccw.c | 203 +++++++--
drivers/scsi/virtio_scsi.c | 50 +-
drivers/vhost/net.c | 31 +-
drivers/vhost/scsi.c | 22 +-
drivers/vhost/vhost.c | 93 ++--
drivers/virtio/virtio.c | 102 ++++-
drivers/virtio/virtio_mmio.c | 17 +-
drivers/virtio/virtio_pci.c | 802 ---------------------------------
drivers/virtio/virtio_pci_common.c | 464 +++++++++++++++++++
drivers/virtio/virtio_pci_legacy.c | 326 ++++++++++++++
drivers/virtio/virtio_ring.c | 109 +++--
net/packet/af_packet.c | 35 +-
tools/virtio/virtio_test.c | 5 +-
tools/virtio/vringh_test.c | 16 +-
drivers/virtio/Makefile | 1 +
include/uapi/linux/Kbuild | 2 +
40 files changed, 2048 insertions(+), 1428 deletions(-)
create mode 100644 drivers/virtio/virtio_pci_common.h
create mode 100644 include/linux/virtio_byteorder.h
rename include/{ => uapi}/linux/virtio_scsi.h (73%)
create mode 100644 include/uapi/linux/virtio_types.h
delete mode 100644 drivers/virtio/virtio_pci.c
create mode 100644 drivers/virtio/virtio_pci_common.c
create mode 100644 drivers/virtio/virtio_pci_legacy.c
^ 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