Home
last modified time | relevance | path

Searched refs:received (Results 1 – 7 of 7) sorted by relevance

/net/9p/
A Dtrans_usbg.c52 struct completion received; member
252 complete(&usb9pfs->received); in usb9pfs_rx_complete()
411 complete(&usb9pfs->received); in p9_usbg_create()
467 ret = wait_for_completion_killable(&usb9pfs->received); in p9_usbg_request()
754 init_completion(&usb9pfs->received); in usb9pfs_alloc()
A Dclient.c1551 u32 rsize, received; in p9_client_read_once() local
1587 "D", &received, &dataptr); in p9_client_read_once()
1595 if (rsize < received) { in p9_client_read_once()
1596 pr_err("bogus RREAD count (%u > %u)\n", received, rsize); in p9_client_read_once()
1602 p9_debug(P9_DEBUG_9P, "<<< RREAD count %u\n", received); in p9_client_read_once()
1605 int n = copy_to_iter(dataptr, received, to); in p9_client_read_once()
1607 if (n != received) { in p9_client_read_once()
1613 iov_iter_revert(to, count - received - iov_iter_count(to)); in p9_client_read_once()
1616 return received; in p9_client_read_once()
/net/rxrpc/
A DKconfig36 Say Y here to inject packet loss by discarding some received and some
/net/bridge/
A DKconfig44 forward multicast traffic based on IGMP/MLD traffic received from
/net/ipv4/
A DKconfig68 Normally, a router decides what to do with a received packet based
98 received packets which look strange and could be evidence of an
536 increase the congestion window by when an ACK is received.
/net/
A DKconfig310 load of received packet processing across multiple CPUs.
/net/netfilter/
A DKconfig1142 1) Web browsers connect, then hang with no data received.

Completed in 19 milliseconds