[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF=yD-J2Sw0=iTuvPe-sa01Ld0D1U6f=R-99WLRKggap_WKdug@mail.gmail.com>
Date: Mon, 2 Jan 2017 17:57:10 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc: Network Development <netdev@...r.kernel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Willem de Bruijn <willemb@...gle.com>,
David Miller <davem@...emloft.net>
Subject: Re: [PATCH v2 net-next 1/2] af_packet: TX_RING support for TPACKET_V3
On Sun, Jan 1, 2017 at 5:45 PM, Sowmini Varadhan
<sowmini.varadhan@...cle.com> wrote:
> Although TPACKET_V3 Rx has some benefits over TPACKET_V2 Rx, *_v3
> does not currently have TX_RING support. As a result an application
> that wants the best perf for Tx and Rx (e.g. to handle request/response
> transacations) ends up needing 2 sockets, one with *_v2 for Tx and
> another with *_v3 for Rx.
>
> This patch enables TPACKET_V2 compatible Tx features in TPACKET_V3
> so that an application can use a single descriptor to get the benefits
> of _v3 RX_RING and _v2 TX_RING. An application may do a block-send by
> first filling up multiple frames in the Tx ring and then triggering a
> transmit. This patch only support fixed size Tx frames for TPACKET_V3,
> and requires that tp_next_offset must be zero.
>
> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@...cle.com>
> ---
> v2: sanity checks on tp_next_offset and corresponding Doc updates
> as suggested by Willem de Bruijn
>
> Documentation/networking/packet_mmap.txt | 9 +++++++--
> net/packet/af_packet.c | 27 +++++++++++++++++++--------
> 2 files changed, 26 insertions(+), 10 deletions(-)
> @@ -4180,9 +4193,7 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u,
> goto out;
> switch (po->tp_version) {
> case TPACKET_V3:
> - /* Transmit path is not supported. We checked
> - * it above but just being paranoid
> - */
> + /* Block transmit is not supported yet */
> if (!tx_ring)
> init_prb_bdqc(po, rb, pg_vec, req_u);
One more point. We should validate the tpacket_req3 input and fail if
unsupported options are passed. Specifically, fail if any of
{tp_retire_blk_tov, tp_sizeof_priv, tp_feature_req_word} is non-zero.
Otherwise looks good to me.
Powered by blists - more mailing lists