lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0835B3720019904CB8F7AA43166CEEB2F18D47C8@RTITMBSVM03.realtek.com.tw>
Date:   Fri, 16 Aug 2019 09:08:41 +0000
From:   Hayes Wang <hayeswang@...ltek.com>
To:     Eric Dumazet <eric.dumazet@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     nic_swsd <nic_swsd@...ltek.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net-next] r8152: divide the tx and rx bottom functions

Eric Dumazet [mailto:eric.dumazet@...il.com]
> Sent: Friday, August 16, 2019 4:20 PM
[...]
> Which callback ?

The USB device has two endpoints for Tx and Rx.
If I submit tx or rx URB to the USB host controller,
the relative callback functions would be called, when
they are finished. For rx, it is read_bulk_callback.
For tx, it is write_bulk_callback.

> After an idle period (no activity, no prior packets being tx-completed ...),
> a packet is sent by the upper stack, enters the ndo_start_xmit() of a network
> driver.
> 
> This driver ndo_start_xmit() simply adds an skb to a local list, and returns.

Base on the current method (without tasklet), when
ndo_start_xmit() is called, napi_schedule is called only
if there is at least one free buffer (!list_empty(&tp->tx_free))
to transmit the packet. Then, the flow would be as following.

    - Call r8152_poll
     -- Call bottom_half
      --- Call tx_bottom
       ---- Call r8152_tx_agg_fill
        ----- submit tx urb

    - Call write_bulk_callback if tx is completed

When the tx transfer is completed, write_bulk_callback would
be called. And it would check if there is any tx packet
in &tp->tx_queue and determine whether it is necessary to
schedule the napi again or not.

> Where/how is scheduled this callback ?

For tx, you could find the following code in r8152_tx_agg_fill().

	usb_fill_bulk_urb(agg->urb, tp->udev, usb_sndbulkpipe(tp->udev, 2),
			  agg->head, (int)(tx_data - (u8 *)agg->head),
			  (usb_complete_t)write_bulk_callback, agg);
	ret = usb_submit_urb(agg->urb, GFP_ATOMIC);

For rx you could find the following code in r8152_submit_rx().

	usb_fill_bulk_urb(agg->urb, tp->udev, usb_rcvbulkpipe(tp->udev, 1),
			  agg->buffer, tp->rx_buf_sz,
			  (usb_complete_t)read_bulk_callback, agg);

	ret = usb_submit_urb(agg->urb, mem_flags);

> Some kind of timer ?
> An (unrelated) incoming packet ?

When the rx or tx is completed, a interrupt of USB
host controller would be triggered. Then, the callback
functions would be called.

Best Regards,
Hayes


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ