Trait NetworkDeviceIfcServerHandler 

pub trait NetworkDeviceIfcServerHandler<___T: Transport = DriverChannel> {
    // Required methods
    fn port_status_changed(
        &mut self,
        request: Request<PortStatusChanged, ___T>,
    ) -> impl Future<Output = ()> + Send;
    fn add_port(
        &mut self,
        request: Request<AddPort, ___T>,
        responder: Responder<AddPort, ___T>,
    ) -> impl Future<Output = ()> + Send;
    fn remove_port(
        &mut self,
        request: Request<RemovePort, ___T>,
    ) -> impl Future<Output = ()> + Send;
    fn complete_rx(
        &mut self,
        request: Request<CompleteRx, ___T>,
    ) -> impl Future<Output = ()> + Send;
    fn complete_tx(
        &mut self,
        request: Request<CompleteTx, ___T>,
    ) -> impl Future<Output = ()> + Send;
    fn delegate_rx_lease(
        &mut self,
        request: Request<DelegateRxLease, ___T>,
    ) -> impl Future<Output = ()> + Send;
    fn update_rx_buffer_params(
        &mut self,
        request: Request<UpdateRxBufferParams, ___T>,
        responder: Responder<UpdateRxBufferParams, ___T>,
    ) -> impl Future<Output = ()> + Send;
    fn request_rx_space(
        &mut self,
        request: Request<RequestRxSpace, ___T>,
    ) -> impl Future<Output = ()> + Send;
}

A server handler for the NetworkDeviceIfc protocol.

See NetworkDeviceIfc for more details.

Required Methods

fn port_status_changed( &mut self, request: Request<PortStatusChanged, ___T>, ) -> impl Future<Output = ()> + Send

Notifies the interface of status changes on port with id.

Port status changes must always be notified through StatusChanged. The interface will not poll ports for status via [NetworkPort.GetStatus].

• request id port identifier.
• request new_status new port’s status.

fn add_port( &mut self, request: Request<AddPort, ___T>, responder: Responder<AddPort, ___T>, ) -> impl Future<Output = ()> + Send

Instantiates a new port with id.

id must not be currently in use by any other ports. ids may be reused once the provided port is destroyed by [NetworkPort.Removed].

Port identifiers do not need to be stable across instantiations or reboots. Port identifiers don’t need to be allocated in any specific order as long as [MAX_PORTS] is not exceeded.

• request id new port identifier.
• request port handle to network port implementation.

fn remove_port( &mut self, request: Request<RemovePort, ___T>, ) -> impl Future<Output = ()> + Send

Destroys port with id.

NOTE: Resources associated with the port must not be freed until [NetworkPort.Removed] is called.

• request id removed port identifier.

fn complete_rx( &mut self, request: Request<CompleteRx, ___T>, ) -> impl Future<Output = ()> + Send

Notifies interface of incoming rx data, contained in RxBuffer.

Callers should attempt to batch as many buffers as possible in a single call. Number of buffers in a single call must be limited to the [DeviceInfo.rx_depth] reported by the NetworkDeviceImpl that is returning the buffers.

Buffers with zero length are considered “unfulfilled”. They’re not reported to any sessions and the buffer space comprising them may be reused. Devices should return any outstanding buffer space as unfulfilled on stop. See [NetworkDeviceImpl.Stop].

By calling CompleteRx the caller relinquishes ownership of all buffers that are being marked as complete.

• request rx buffers containing incoming data.

fn complete_tx( &mut self, request: Request<CompleteTx, ___T>, ) -> impl Future<Output = ()> + Send

Notifies interface of complete transmit buffers.

Callers should attempt to batch as many buffers as possible in a single call.

Number of buffers in a single call must be limited to the [DeviceInfo.tx_depth] reported by the NetworkDeviceImpl that is returning the buffers.

By calling CompleteTx the caller relinquishes ownership of all buffers that are being returned.

• request tx transmit results.

fn delegate_rx_lease( &mut self, request: Request<DelegateRxLease, ___T>, ) -> impl Future<Output = ()> + Send

Transfers a receive wake lease up to the application.

Devices that allow applications to fully deal with a frame after a wake from network traffic may use this method as a “lease baton passing” strategy. Applications that support wake handling hold on to the lease until the rx traffic is fully processed.

Devices must keep track of the number of rx frames sent over [NetworkDeviceIfc.CompleteRx] and use the latest issued frame number as [fuchsia.hardware.network/DelegatedRxLease.hold_until_frame] to guarantee processing. Every frame successfully given to CompleteRx should increase the rx frame count. Note that the frame number is 1-based, see hold_until_frame docs for details.

Note that this is a one-way method and flow-control is enforced via the regular rx space -> rx completion flow.

fn update_rx_buffer_params( &mut self, request: Request<UpdateRxBufferParams, ___T>, responder: Responder<UpdateRxBufferParams, ___T>, ) -> impl Future<Output = ()> + Send

Provides the NetworkDeviceIfc with a set of parameters to use for buffer management.

• ZX_ERR_INVALID_VALUE if the given parameters are invalid.

fn request_rx_space( &mut self, request: Request<RequestRxSpace, ___T>, ) -> impl Future<Output = ()> + Send

Notifies network device of buffer starvation.

The server of this protocol needs to queue more RX buffers into the implementation. The network device impl can ask for a number of buffers, but it is used as a hint and the server tries its best to fulfill the request.

This is a better-effort method, if the network-device is also out of Rx space buffers, then there is nothing more we can do.

Note that this is a one-way asynchronous call, this only serves as a signaling method to the platform driver, the queue action may not happen inline with interrupt handling. Packets may get dropped within the time window. The NetworkDeviceImpl can raise this signal when a certain threshold is hit instead of waiting for the buffer space to be actually empty.

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors