Searched full:received (Results 1 – 25 of 393) sorted by relevance
12345678910>>...16
| /Documentation/networking/device_drivers/ethernet/mellanox/mlx5/ |
| D | counters.rst | 145 - The number of packets received on ring i.
149 - The number of bytes received on ring i.
191 - Number of received packets processed using hardware-accelerated GRO. The
192 number of hardware GRO offloaded packets received on ring i. Only true GRO
197 - Number of received bytes processed using hardware-accelerated GRO. The
198 number of hardware GRO offloaded bytes received on ring i. Only true GRO
238 - The number of LRO packets received on ring i [#accel]_.
242 - The number of LRO bytes received on ring i [#accel]_.
246 - The number of received packets where the ECN mark was turned on.
250 - The number of dropped received packets due to length which arrived to RQ
[all …]
|
| /Documentation/networking/device_drivers/ethernet/altera/ |
| D | altera_tse.rst | 95 received, the DMA logic generates an interrupt. The driver handles a receive
164 received. This count does not include any error packets such as CRC errors,
170 is received.
175 received.
183 successfully received by the controller.
191 received by the network controller.
194 a count of the number of packets received containing errors that prevented the
201 statistic is a count of the number of packets received that were not addressed
205 statistic is a count of the number of packets received that were addressed to
209 statistic is a count of the number of packets received that were addressed to
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-class-net-statistics | 14 Indicates the number of multicast packets received by this
22 Indicates the number of bytes received by this network device.
31 Indicates the number of compressed packets received by this
40 Indicates the number of packets received with a CRC (FCS) error
49 Indicates the number of packets received by the network device
76 Indicates the number of received frames with error, such as
86 Indicates the number of received error packet with a length
95 Indicates the number of received packets that have been missed
104 Indicates the number of received packets that were dropped on
112 Indicates the number of received packets that are oversized
[all …]
|
| D | debugfs-scmi-raw | 9 Any subsequently received response can be read from this same
24 Any subsequently received response can be read from this same
26 Any additional delayed response received afterwards can be read
39 generally unexpectedly received SCMI message, for instance <n>,
61 causes the internal queues of any kind of received message,
77 Any subsequently received response can be read from this same
101 Any subsequently received response can be read from this same
104 Any additional delayed response received afterwards can be read
|
| D | sysfs-devices-xenbus | 12 Total number of Xen events received for a Xen pv device
28 Number of events received for a Xen pv device which did not
|
| D | sysfs-devices-platform-ipmi | 134 events (RO) Number of IPMI events received from
154 received.
210 alerts (RO) Number of alerts received.
219 received.
222 received.
224 events (RO) Number of received events.
|
| D | debugfs-hisi-sec | 132 Description: Dump the total number of received requests.
145 to be received.
151 Description: Dump the total number of invalid requests being received.
158 to be received.
|
| /Documentation/userspace-api/media/cec/ |
| D | cec-pin-error-inj.rst | 47 # <op>[,<mode>] rx-add-byte add a spurious byte to the received CEC message
48 # <op>[,<mode>] rx-remove-byte remove the last byte from the received CEC message
101 received or transmitted message, ``always`` to always trigger the error
105 So '``any rx-nack``' will NACK the next received CEC message,
106 '``any,always rx-nack``' will NACK all received CEC messages and
108 received and do that only for every other received message.
163 otherwise the opcode hasn't been received yet. This tests if the
170 Add a spurious 0x55 byte to the received CEC message, provided
175 Remove the last byte from the received CEC message, provided it
182 As soon as a start bit has been received the CEC adapter will switch
[all …]
|
| D | cec-ioc-receive.rst | 42 If the file descriptor is in non-blocking mode and there are no received
48 A received message can be:
50 1. a message received from another CEC device (the ``sequence`` field will
107 - Timestamp in ns of when the last byte of the message was received.
119 for a message to be received before timing out. If it is set to 0,
129 to associate the received message with the original transmit.
134 received message with the original transmit.
162 synchronized with the contents of the received message.
165 - The status bits of the received message. See
332 - The message was received successfully.
[all …]
|
| /Documentation/devicetree/bindings/pci/ |
| D | xlnx,nwl-pcie.yaml | 34 - description: interrupt asserted when miscellaneous interrupt is received
36 - description: interrupt asserted when a legacy interrupt is received
37 - description: msi1 interrupt asserted when an MSI is received
38 - description: msi0 interrupt asserted when an MSI is received
|
| D | xlnx,xdma-host.yaml | 38 - description: interrupt asserted when miscellaneous interrupt is received.
39 - description: msi0 interrupt asserted when an MSI is received.
40 - description: msi1 interrupt asserted when an MSI is received.
|
| /Documentation/infiniband/ |
| D | user_mad.rst | 42 MADs are received using read(). The receive side now supports
46 If the buffer passed is not large enough to hold the received
77 fields will be filled in with information on the received MAD. For
81 to ETIMEDOUT. Otherwise when a MAD has been successfully received,
122 index of received MADs. A new layout for struct ib_user_mad_hdr
|
| /Documentation/networking/ |
| D | iso15765-2.rst | 61 composing such block (``stmin``). Once this information has been received, the
99 is sent and received by the userspace application using these calls. The address
170 * ``CAN_ISOTP_RX_PADDING``: enable padding for the received frames, using
173 * ``CAN_ISOTP_CHK_PAD_LEN``: check for correct padding length on the received
176 * ``CAN_ISOTP_CHK_PAD_DATA``: check padding bytes on the received frames
184 * ``CAN_ISOTP_FORCE_TXSTMIN``: ignore stmin from received FC; normally
218 * ``rxpad_content``: byte used as padding value for received frames.
303 a 32bit unsigned integer; received Consecutive Frames (CF) which timestamps
325 received or not is decided when the First Frame is received.
379 /* Data can now be received using read(s, ...) and sent using write(s, ...) */
|
| D | oa-tc6-framework.rst | 69 In parallel, receive data chunks are received on MISO. Each receive data
153 - Forwards the received Ethernet frame from 10Base-T1x MAC-PHY to n/w
242 received from the MAC-PHY. The SPI host should not write more data chunks
249 first data header this interrupt will be deasserted and the received
273 HDRB (Bit 30) - Received Header Bad. When set, indicates that the MAC-PHY
274 received a control or data header with a parity error.
308 containing the first byte of a new received Ethernet
310 beginning of the received Ethernet frame (RTSA = 1)
316 received Ethernet frame. This bit is only valid at the end
317 of a received Ethernet frame (EV = 1) and shall be zero at
[all …]
|
| D | rxrpc.rst | 150 A hard-ACK indicates to the far side that all the data received to a point
151 has been received and processed; a soft-ACK indicates that the data has
152 been received but may yet be discarded and re-requested. The sender may
159 received and the final hard-ACK on the last packet of the reply has
202 (#) If an ICMP error is received, all calls affected by that error will be
212 followed by the reply being received with one or more recvmsgs.
229 (#) Once the application has received the last message associated with a call,
234 (#) In the server, a request is received with one or more recvmsgs, then the
236 is received with a last recvmsg.
265 (#) When the kernel has received and set up an incoming call, it sends a
[all …]
|
| D | tls.rst | 104 be received before decryption can happen.
111 Received data is decrypted directly in to the user buffer if it is
116 ``EINVAL`` is returned if the TLS version in the received message does not
119 ``EMSGSIZE`` is returned if the received message is too big.
169 returned if a control message is received. Data messages may be
170 received without a cmsg buffer set.
|
| D | x25-iface.rst | 55 received over the LAPB link.
80 call "netif_rx" to deliver the received packets. Instead, it should
|
| /Documentation/networking/device_drivers/ethernet/netronome/ |
| D | nfp.rst | 279 * The received packet is larger than the max buffer size on the host.
299 - Total number of bytes received.
303 - Unicast bytes received.
307 - Multicast bytes received.
311 - Broadcast bytes received.
315 - Total number of packets received.
319 - Multicast packets received.
323 - Broadcast packets received.
337 * An invalid packet descriptor was received over PCIe.
|
| /Documentation/admin-guide/media/ |
| D | si476x.rst | 76 0x02 received Number of received RDS blocks
107 RSQ(Received Signal Quality)
121 0x02 snrhint 0 - received signal's SNR has not
123 1 - received signal's SNR has
159 RSQ(Received Signal Quality) for primary tuner only. Layout is as
|
| /Documentation/networking/device_drivers/cellular/qualcomm/ |
| D | rmnet.rst | 46 Reserved bits must be zero when sent and ignored when received.
72 Reserved bits must be zero when sent and ignored when received.
93 Reserved bits must be zero when sent and ignored when received.
155 Reserved bits must be zero when sent and ignored when received.
|
| /Documentation/translations/zh_CN/core-api/irq/ |
| D | irq-affinity.rst | 43 6029 packets transmitted, 6027 packets received, 0% packet loss
61 2779 packets transmitted, 2777 packets received, 0% packet loss
|
| /Documentation/devicetree/bindings/iio/proximity/ |
| D | devantech-srf04.yaml | 17 until it is received once again
47 out and reset when the first echo is received.
|
| /Documentation/virt/kvm/ |
| D | halt-polling.rst | 47 During polling if a wakeup source is received within the halt polling interval,
49 received during the polling interval (and thus schedule is invoked) there are
57 will be received while the host is polling and the latency benefits will be
58 received. The polling interval is grown in the function grow_halt_poll_ns() and
76 invoked and a wakeup source received (irrespective of
|
| /Documentation/devicetree/bindings/sound/ |
| D | cs35l35.txt | 27 0 = Data Packet received on Left I2S Channel
28 1 = Data Packet received on Right I2S Channel
31 0 = Data Packet received on Left I2S Channel
32 1 = Data Packet received on Right I2S Channel
|
| /Documentation/networking/device_drivers/ethernet/freescale/ |
| D | dpaa.rst | 159 different traffic flows received by one interface to be processed by different
192 and L4 source and destination ports, in present in the received frame.
193 When RSS is disabled, all traffic received by a certain interface is
194 received on the default Rx frame queue. The default DPAA Rx frame
195 queues are configured to put the received traffic into a pool channel
200 is that only one CPU at a time can service the traffic received by a
|
12345678910>>...16